Celebrate pull requests when their number or commit SHA matches a fun pattern.
The repository also tracks TODO and FIXME markers with gh-counter.
It also tracks built action artifact size with
gh-build-size.
By default, happy-commit posts a managed PR comment when it finds one of these built-in patterns:
- Celebrate when issue number reaches 10, 100, 1000, ... etc.
- Celebrate when issue number is all sevens (e.g. 777, 7777, ... etc.)
- Celebrate when commit id contains lucky number (e.g. 7, 77, 777, ... etc.)
- Celebrate when commit id is a sequence of digits (e.g. 123, 1234, ... etc.)
- Celebrate when commit id is a hexspeaking number (e.g. deadbeef, cafe, c0ffee, ... etc.)
- Notify when issue number is unlucky number (e.g. 666, ... etc.)
The exact built-in rules live in src/rules.ts.
name: happy-commit
on:
pull_request_target:
permissions:
contents: read
pull-requests: write
issues: write
jobs:
happy:
runs-on: ubuntu-latest
steps:
- uses: kitsuyui/happy-commit@v1
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
max-expected-occurrences: 1This action only needs pull-request metadata and commit ids from the GitHub API, so the published action can run without actions/checkout. pull_request_target is the safer default when you want to comment on pull requests from forks.
| Input | Required | Default | Description |
|---|---|---|---|
github-token |
Yes | none | Token used to read pull request metadata and create or update the managed comment |
additional-rules |
No | none | JSON array of extra pr or commit rules to evaluate in addition to the built-in set |
max-expected-occurrences |
No | none | Optional rarity ceiling for built-in rules. Lower values celebrate only rarer events |
Legacy input names (GITHUB_TOKEN, additional_rules, and max_expected_occurrences) are still accepted for compatibility. The token requirement is validated at runtime so either github-token or GITHUB_TOKEN can satisfy it.
max-expected-occurrences is optional. If you leave it unset, happy-commit behaves exactly like the classic version and evaluates the built-in rules without any rarity filter.
If you set it, built-in rules are celebrated only when they are still rare enough at the current repository size. For pull request numbers, happy-commit uses the current PR number as the search range. For commit hashes, it uses the total number of commits on the default branch to estimate how often a pattern should have appeared by now.
In practice, 1 is a reasonable starting point if you want to celebrate only events that should happen about once or less at the current repository scale. Smaller values make the action stricter. additional-rules are treated as explicit user intent and are not filtered by this rarity threshold.
You can add your own rules with additional-rules. The value is a JSON array, and each rule must contain:
| Field | Required | Description |
|---|---|---|
kind |
Yes | Either pr or commit |
rule |
Yes | Regular expression pattern evaluated against the PR number or commit SHA |
message |
Yes | Mustache template rendered into the comment when the rule matches |
The following Mustache variables are available in message, depending on kind:
| Variable | Available when | Description |
|---|---|---|
{{prNum}} |
kind: "pr" |
Pull request number as a string |
{{commitId}} |
kind: "commit" |
Commit SHA |
{{matched}} |
both | First capture of rule matched against the target value |
For example, this rule celebrates any commit SHA containing 1.
jobs:
happy:
runs-on: ubuntu-latest
steps:
- uses: kitsuyui/happy-commit@v1
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
additional-rules: |
[
{
"kind": "commit",
"rule": "(?:1)",
"message": "custom message! `{{commitId}}` is lucky! It contains **{{matched}}**"
}
]This repository keeps a local example workflow in .github/workflows/main.yml. It uses pull_request and uses: ./ so changes in the current branch are tested before release. That pattern should stay limited to the action repository itself, because a local action from an untrusted fork must not run with pull_request_target.
Install lefthook and run:
lefthook installThis sets up the following Git hooks:
- pre-commit: runs
bun run lint(Biome checks) — fast static feedback before each commit. - pre-push: runs
bun run lintandbun run test— full local validation before pushing.
CI still runs the complete suite on every pull request and push to main; the hooks bring that feedback earlier in your workflow.
Releases are published from GitHub Releases and version tags. The release
workflow verifies the tagged commit by installing dependencies, running lint and
tests, rebuilding dist/, and checking that the release tag matches
package.json.
Before publishing a release, update package.json to the release version,
rebuild and commit dist/, and create a GitHub Release for the matching tag.
Use the manual Release workflow dispatch to re-run the same verification for an
existing tag.
MIT