@htekdev/actions-debugger 1.0.47 → 1.0.48
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -0,0 +1,96 @@
|
|
|
1
|
+
id: permissions-auth-036
|
|
2
|
+
title: 'GITHUB_TOKEN cannot push commits to branches protected by "Require signed commits" — token identity cannot sign'
|
|
3
|
+
category: permissions-auth
|
|
4
|
+
severity: error
|
|
5
|
+
tags:
|
|
6
|
+
- github-token
|
|
7
|
+
- signed-commits
|
|
8
|
+
- branch-protection
|
|
9
|
+
- gpg
|
|
10
|
+
- push
|
|
11
|
+
- protected-branch
|
|
12
|
+
patterns:
|
|
13
|
+
- regex: 'GH006.*Protected branch.*signed|Commits must have verified signatures'
|
|
14
|
+
flags: 'i'
|
|
15
|
+
- regex: 'Changes must be signed|protected branch.*signed.*commits'
|
|
16
|
+
flags: 'i'
|
|
17
|
+
error_messages:
|
|
18
|
+
- 'remote: error: GH006: Protected branch update failed for refs/heads/main.'
|
|
19
|
+
- 'remote: error: Commits must have verified signatures.'
|
|
20
|
+
- 'remote: error: Changes must be signed.'
|
|
21
|
+
root_cause: |
|
|
22
|
+
GitHub's "Require signed commits" branch protection rule requires every pushed commit
|
|
23
|
+
to carry a verified GPG or SSH signature. The GITHUB_TOKEN is a short-lived bearer token
|
|
24
|
+
scoped to a workflow run — it has no associated GPG or SSH signing key and cannot produce
|
|
25
|
+
verified commit signatures.
|
|
26
|
+
|
|
27
|
+
This means any workflow that creates commits and pushes them using GITHUB_TOKEN will fail
|
|
28
|
+
on branches protected by "Require signed commits", regardless of the token's permission
|
|
29
|
+
level. Having contents: write permission is necessary but not sufficient: the signature
|
|
30
|
+
requirement is enforced by a separate push hook after permission checks pass.
|
|
31
|
+
|
|
32
|
+
Common workflow patterns that hit this:
|
|
33
|
+
- Auto-commit actions (stefanzweifel/auto-commit-action, EndBug/add-and-commit) that
|
|
34
|
+
commit generated files (changelogs, coverage badges, built assets) back to main
|
|
35
|
+
- Release workflows that bump version numbers in committed files before tagging
|
|
36
|
+
- Automated dependency update workflows that commit lockfile changes
|
|
37
|
+
- Documentation generation workflows that commit generated API docs or OpenAPI specs
|
|
38
|
+
|
|
39
|
+
The GH006 error appears in the push step's output but the job may not fail loudly if
|
|
40
|
+
the step's exit code is not checked carefully. In some auto-commit actions, the failure
|
|
41
|
+
surfaces as an unexpected empty push with no error surfaced to the workflow summary.
|
|
42
|
+
fix: |
|
|
43
|
+
Option 1 — Create a pull request instead of direct push (recommended): Use
|
|
44
|
+
peter-evans/create-pull-request or similar to push the auto-generated commit to a
|
|
45
|
+
feature branch, then open a PR. Feature branches are not subject to the main branch's
|
|
46
|
+
"Require signed commits" protection.
|
|
47
|
+
|
|
48
|
+
Option 2 — GitHub App with bypass: Create a GitHub App and add it to the branch
|
|
49
|
+
protection "Allow specific actors to bypass required pull request reviews and required
|
|
50
|
+
status checks" bypass list. Generate tokens for the App in the workflow and push with
|
|
51
|
+
the App token. The App's bot commits can bypass the signed-commits requirement if
|
|
52
|
+
explicitly listed as a bypass actor.
|
|
53
|
+
|
|
54
|
+
Option 3 — Signed commits via GitHub App SSH key: Configure a GitHub App with an
|
|
55
|
+
SSH signing key. Use the App installation token and the App's SSH key for commit
|
|
56
|
+
signing via GIT_COMMITTER_EMAIL and gpg.format = ssh configuration.
|
|
57
|
+
|
|
58
|
+
The GITHUB_TOKEN itself cannot be configured for commit signing — this is a platform
|
|
59
|
+
limitation with no in-token workaround.
|
|
60
|
+
fix_code:
|
|
61
|
+
- language: yaml
|
|
62
|
+
label: 'Create a pull request instead of pushing directly — avoids signed commits requirement on main'
|
|
63
|
+
code: |
|
|
64
|
+
jobs:
|
|
65
|
+
update-generated:
|
|
66
|
+
runs-on: ubuntu-latest
|
|
67
|
+
permissions:
|
|
68
|
+
contents: write
|
|
69
|
+
pull-requests: write
|
|
70
|
+
steps:
|
|
71
|
+
- uses: actions/checkout@v4
|
|
72
|
+
|
|
73
|
+
- name: Regenerate files
|
|
74
|
+
run: make generate
|
|
75
|
+
|
|
76
|
+
- name: Create pull request for generated output
|
|
77
|
+
uses: peter-evans/create-pull-request@v7
|
|
78
|
+
with:
|
|
79
|
+
commit-message: 'chore: regenerate auto-generated files'
|
|
80
|
+
branch: automated/regenerate-output
|
|
81
|
+
title: 'chore: automated file regeneration'
|
|
82
|
+
body: 'Automated regeneration triggered by CI. Merge after review.'
|
|
83
|
+
# Commit targets the feature branch, not main — signed-commits rule on
|
|
84
|
+
# main does not apply to the automated/ branch
|
|
85
|
+
prevention:
|
|
86
|
+
- 'Before enabling "Require signed commits" on a branch, audit all workflows that push commits using GITHUB_TOKEN to that branch'
|
|
87
|
+
- 'Use the create-pull-request pattern for auto-generated commits rather than pushing directly to protected branches'
|
|
88
|
+
- 'Document in workflow files that GITHUB_TOKEN cannot push to branches with signed-commits protection'
|
|
89
|
+
- 'If a GitHub App bypass is used, rotate the App private key regularly and scope permissions to the minimum required'
|
|
90
|
+
docs:
|
|
91
|
+
- url: 'https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-signed-commits'
|
|
92
|
+
label: 'GitHub Docs: Require signed commits branch protection'
|
|
93
|
+
- url: 'https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification'
|
|
94
|
+
label: 'GitHub Docs: About commit signature verification'
|
|
95
|
+
- url: 'https://github.com/orgs/community/discussions/13836'
|
|
96
|
+
label: 'GitHub Community #13836: GITHUB_TOKEN cannot push to branch requiring signed commits'
|
|
@@ -0,0 +1,100 @@
|
|
|
1
|
+
id: runner-environment-103
|
|
2
|
+
title: "actions/setup-go cache skipped with 'no file matched go.sum' when go.sum is absent or not at workspace root"
|
|
3
|
+
category: runner-environment
|
|
4
|
+
severity: warning
|
|
5
|
+
tags:
|
|
6
|
+
- setup-go
|
|
7
|
+
- go
|
|
8
|
+
- cache
|
|
9
|
+
- go-sum
|
|
10
|
+
- monorepo
|
|
11
|
+
- cache-miss
|
|
12
|
+
- cache-dependency-path
|
|
13
|
+
patterns:
|
|
14
|
+
- regex: 'No file.*matched.*go\.sum|go\.sum.*not.*found.*cache'
|
|
15
|
+
flags: 'i'
|
|
16
|
+
- regex: 'setup-go.*cache.*skip|Unable to find.*go\.sum'
|
|
17
|
+
flags: 'i'
|
|
18
|
+
error_messages:
|
|
19
|
+
- 'Warning: No file in /home/runner/work/repo/repo matched to [**/go.sum, !**/vendor/**], make sure you have checked out the target repository'
|
|
20
|
+
- 'go.sum not found, module cache will not be saved'
|
|
21
|
+
- 'Cache miss — no go.sum file located at expected path'
|
|
22
|
+
root_cause: |
|
|
23
|
+
actions/setup-go uses go.sum as the cache key hash source. When cache: true (the default
|
|
24
|
+
since setup-go@v4), the action runs hashFiles('**/go.sum') to compute the cache key.
|
|
25
|
+
If no go.sum file is found anywhere in the workspace, the action emits a warning and
|
|
26
|
+
silently skips saving and restoring the module cache entirely — the job continues with
|
|
27
|
+
exit 0 but all Go dependencies are downloaded from scratch on every run.
|
|
28
|
+
|
|
29
|
+
Common root causes:
|
|
30
|
+
|
|
31
|
+
1. New project: go mod tidy has not been run — go.sum does not yet exist in the repo.
|
|
32
|
+
|
|
33
|
+
2. Monorepo layout: Go modules live under subdirectories (e.g., services/api/go.sum).
|
|
34
|
+
The default glob **/go.sum should find nested files, but when combined with the
|
|
35
|
+
!**/vendor/** exclusion or when the repo structure is non-standard, detection can fail.
|
|
36
|
+
|
|
37
|
+
3. Go workspace (go.work): modules are organized under subdirectories managed by a
|
|
38
|
+
go.work file; individual go.sum files may be present but not at the expected root.
|
|
39
|
+
|
|
40
|
+
4. Ordering issue: actions/setup-go runs before actions/checkout, so go.sum is not
|
|
41
|
+
yet in the workspace when the cache key is computed.
|
|
42
|
+
|
|
43
|
+
5. go.sum is listed in .gitignore (non-standard but seen in internal tooling repos
|
|
44
|
+
that regenerate dependencies on every run).
|
|
45
|
+
|
|
46
|
+
The missing-cache warning is only visible in the setup-go step's log output and does
|
|
47
|
+
not fail the workflow. On large Go projects, silent cache bypass wastes 60-120+ seconds
|
|
48
|
+
downloading modules from proxy.golang.org on every CI run.
|
|
49
|
+
fix: |
|
|
50
|
+
For monorepo or nested module layouts, explicitly set cache-dependency-path to the
|
|
51
|
+
location of the go.sum file(s). A glob pattern can match multiple modules if needed.
|
|
52
|
+
|
|
53
|
+
For new projects: run go mod tidy locally and commit go.sum before pushing.
|
|
54
|
+
|
|
55
|
+
For go.work workspaces: list each module's go.sum explicitly in cache-dependency-path
|
|
56
|
+
to ensure all modules participate in the cache key.
|
|
57
|
+
|
|
58
|
+
Always confirm actions/checkout runs before actions/setup-go in the steps list.
|
|
59
|
+
fix_code:
|
|
60
|
+
- language: yaml
|
|
61
|
+
label: 'Set cache-dependency-path for a nested module in a monorepo'
|
|
62
|
+
code: |
|
|
63
|
+
steps:
|
|
64
|
+
- uses: actions/checkout@v4
|
|
65
|
+
|
|
66
|
+
- uses: actions/setup-go@v5
|
|
67
|
+
with:
|
|
68
|
+
go-version: '1.22'
|
|
69
|
+
cache: true
|
|
70
|
+
# Explicit path overrides default glob — required when go.sum is not at repo root
|
|
71
|
+
cache-dependency-path: services/api/go.sum
|
|
72
|
+
|
|
73
|
+
- language: yaml
|
|
74
|
+
label: 'Multiple modules in a go.work workspace — list all go.sum paths'
|
|
75
|
+
code: |
|
|
76
|
+
steps:
|
|
77
|
+
- uses: actions/checkout@v4
|
|
78
|
+
|
|
79
|
+
- uses: actions/setup-go@v5
|
|
80
|
+
with:
|
|
81
|
+
go-version: '1.22'
|
|
82
|
+
cache: true
|
|
83
|
+
# Multi-line value: each module go.sum contributes to the aggregate cache key
|
|
84
|
+
cache-dependency-path: |
|
|
85
|
+
services/api/go.sum
|
|
86
|
+
services/worker/go.sum
|
|
87
|
+
pkg/shared/go.sum
|
|
88
|
+
prevention:
|
|
89
|
+
- 'Always run go mod tidy before the first commit to ensure go.sum exists in the repository'
|
|
90
|
+
- 'In monorepos, explicitly set cache-dependency-path rather than relying on the default **/go.sum glob'
|
|
91
|
+
- 'Check the setup-go step output for "No file matched" warnings — caching may be silently disabled without failing the job'
|
|
92
|
+
- 'Ensure actions/checkout runs before actions/setup-go so go.sum is present when the cache key is computed'
|
|
93
|
+
- 'Never add go.sum to .gitignore — it is required for reproducible builds and module cache keying'
|
|
94
|
+
docs:
|
|
95
|
+
- url: 'https://github.com/actions/setup-go#caching-dependency-files-and-build-outputs'
|
|
96
|
+
label: 'actions/setup-go: Caching dependency files and build outputs'
|
|
97
|
+
- url: 'https://github.com/actions/setup-go/issues/289'
|
|
98
|
+
label: 'setup-go #289: Cache fails when go.sum not at repository root'
|
|
99
|
+
- url: 'https://docs.github.com/en/actions/use-cases-and-examples/building-and-testing/building-and-testing-go'
|
|
100
|
+
label: 'GitHub Docs: Building and testing Go'
|
|
@@ -0,0 +1,107 @@
|
|
|
1
|
+
id: silent-failures-051
|
|
2
|
+
title: 'environment.url expression evaluates to empty string when referencing steps.*.outputs — resolved before steps run'
|
|
3
|
+
category: silent-failures
|
|
4
|
+
severity: silent-failure
|
|
5
|
+
tags:
|
|
6
|
+
- environment
|
|
7
|
+
- deployment-url
|
|
8
|
+
- step-outputs
|
|
9
|
+
- expression-evaluation
|
|
10
|
+
- dynamic-url
|
|
11
|
+
- deployment-widget
|
|
12
|
+
patterns:
|
|
13
|
+
- regex: 'environment.*url.*steps\.\w+\.outputs\.\w+'
|
|
14
|
+
flags: 'i'
|
|
15
|
+
- regex: 'deployment.*url.*empty|environment.*url.*not.*set|page_url.*empty'
|
|
16
|
+
flags: 'i'
|
|
17
|
+
error_messages:
|
|
18
|
+
- 'Deployment environment shows no URL in GitHub UI despite environment.url referencing a step output'
|
|
19
|
+
- 'Deployment URL is empty string — steps.deploy.outputs.url is non-empty in the step logs'
|
|
20
|
+
root_cause: |
|
|
21
|
+
The jobs.<id>.environment.url field is evaluated at job scheduling time — before ANY steps
|
|
22
|
+
in the job have run and before any step outputs exist. Expressions that reference
|
|
23
|
+
steps.*.outputs.* from the same job silently resolve to empty string. GitHub does not
|
|
24
|
+
emit a warning or error when this occurs.
|
|
25
|
+
|
|
26
|
+
This is a fundamental evaluation ordering constraint: the environment block (both name and
|
|
27
|
+
url) is part of the workflow plan GitHub evaluates once when the job is queued. The job
|
|
28
|
+
has not yet started, so step outputs are undefined and resolve to empty.
|
|
29
|
+
|
|
30
|
+
Contexts SAFE to use in environment.url (available at scheduling time):
|
|
31
|
+
- github.* — static for the run
|
|
32
|
+
- vars.* — repository/org/environment variables
|
|
33
|
+
- inputs.* — workflow_dispatch or workflow_call inputs
|
|
34
|
+
- needs.<prior-job>.outputs.* — outputs from already-completed upstream jobs
|
|
35
|
+
- env.* declared at the job level
|
|
36
|
+
|
|
37
|
+
Contexts that silently resolve to empty in environment.url:
|
|
38
|
+
- steps.*.outputs.* — step has not run yet
|
|
39
|
+
- steps.*.conclusion / steps.*.outcome — step has not run yet
|
|
40
|
+
- Any runtime-computed value from within the same job
|
|
41
|
+
|
|
42
|
+
Common scenario: a deploy step creates a preview URL (e.g., Vercel preview, Heroku review
|
|
43
|
+
app, AWS CloudFormation output), writes it to GITHUB_OUTPUT, and the developer tries to
|
|
44
|
+
surface it via environment.url so it appears in the GitHub deployment widget on the PR.
|
|
45
|
+
The widget shows no URL, and no error is ever raised.
|
|
46
|
+
fix: |
|
|
47
|
+
Route the dynamic deployment URL through job outputs of the deploy job, then reference
|
|
48
|
+
needs.deploy.outputs.<name> in a dependent job's environment.url. The needs context IS
|
|
49
|
+
available at scheduling time for downstream jobs because the upstream job has already
|
|
50
|
+
completed.
|
|
51
|
+
|
|
52
|
+
For cases where the URL can be computed entirely from pre-execution contexts (github.ref_name,
|
|
53
|
+
inputs.*, vars.*), use a static URL expression directly in environment.url without
|
|
54
|
+
any step output dependency.
|
|
55
|
+
fix_code:
|
|
56
|
+
- language: yaml
|
|
57
|
+
label: 'Two-job pattern — expose deployment URL as job output, reference via needs in downstream job'
|
|
58
|
+
code: |
|
|
59
|
+
jobs:
|
|
60
|
+
deploy:
|
|
61
|
+
runs-on: ubuntu-latest
|
|
62
|
+
outputs:
|
|
63
|
+
# Promote step output to job output — available to downstream jobs via needs
|
|
64
|
+
app_url: ${{ steps.deploy.outputs.url }}
|
|
65
|
+
steps:
|
|
66
|
+
- uses: actions/checkout@v4
|
|
67
|
+
- name: Deploy
|
|
68
|
+
id: deploy
|
|
69
|
+
run: |
|
|
70
|
+
DEPLOY_URL="https://preview-${{ github.run_id }}.example.com"
|
|
71
|
+
echo "url=${DEPLOY_URL}" >> $GITHUB_OUTPUT
|
|
72
|
+
|
|
73
|
+
link-deployment:
|
|
74
|
+
needs: deploy
|
|
75
|
+
runs-on: ubuntu-latest
|
|
76
|
+
environment:
|
|
77
|
+
name: preview
|
|
78
|
+
# needs.deploy.outputs.* resolves correctly — deploy job already completed
|
|
79
|
+
url: ${{ needs.deploy.outputs.app_url }}
|
|
80
|
+
steps:
|
|
81
|
+
- run: echo "Linked deployment to ${{ needs.deploy.outputs.app_url }}"
|
|
82
|
+
|
|
83
|
+
- language: yaml
|
|
84
|
+
label: 'Static URL pattern using pre-execution context (no step output dependency)'
|
|
85
|
+
code: |
|
|
86
|
+
jobs:
|
|
87
|
+
deploy:
|
|
88
|
+
runs-on: ubuntu-latest
|
|
89
|
+
environment:
|
|
90
|
+
name: preview
|
|
91
|
+
# github.ref_name is available at scheduling time — always resolves correctly
|
|
92
|
+
url: 'https://preview-${{ github.ref_name }}.example.com'
|
|
93
|
+
steps:
|
|
94
|
+
- uses: actions/checkout@v4
|
|
95
|
+
- run: echo "deploying..."
|
|
96
|
+
prevention:
|
|
97
|
+
- 'Never reference steps.*.outputs.* directly in environment.url — promote to a job output and reference via needs in a downstream job instead'
|
|
98
|
+
- 'Test environment.url by checking the deployment widget on a pull request — an empty URL indicates the expression evaluated to empty string at scheduling time'
|
|
99
|
+
- 'Document the two-job deploy-then-link pattern in team workflow templates to prevent rediscovery'
|
|
100
|
+
- 'If the URL requires a step output, always add an outputs: block to the job and reference it via needs.<job>.outputs.<name> in a downstream job'
|
|
101
|
+
docs:
|
|
102
|
+
- url: 'https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idenvironment'
|
|
103
|
+
label: 'GitHub Docs: jobs.<job_id>.environment syntax'
|
|
104
|
+
- url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/passing-information-between-jobs'
|
|
105
|
+
label: 'GitHub Docs: Passing information between jobs'
|
|
106
|
+
- url: 'https://github.com/orgs/community/discussions/9366'
|
|
107
|
+
label: 'GitHub Community #9366: Dynamic environment URL from step output resolves to empty'
|
|
@@ -0,0 +1,73 @@
|
|
|
1
|
+
id: triggers-036
|
|
2
|
+
title: 'branches-ignore filter does not suppress tag pushes — tags always fire unless tags-ignore is also specified'
|
|
3
|
+
category: triggers
|
|
4
|
+
severity: silent-failure
|
|
5
|
+
tags:
|
|
6
|
+
- push
|
|
7
|
+
- branches-ignore
|
|
8
|
+
- tags
|
|
9
|
+
- tag-push
|
|
10
|
+
- filter
|
|
11
|
+
- trigger-bypass
|
|
12
|
+
patterns:
|
|
13
|
+
- regex: 'on.*push.*branches-ignore|branches-ignore.*\*\*'
|
|
14
|
+
flags: 'i'
|
|
15
|
+
- regex: 'tag.*push.*trigger.*unexpected|branches-ignore.*tags.*still.*fire'
|
|
16
|
+
flags: 'i'
|
|
17
|
+
error_messages:
|
|
18
|
+
- "Workflow triggered by tag push despite branches-ignore: ['**'] — expected no branch pushes to trigger"
|
|
19
|
+
- 'v1.2.3 tag push fires a workflow that should only run on branch pushes'
|
|
20
|
+
root_cause: |
|
|
21
|
+
GitHub Actions push event filters (branches:, branches-ignore:, paths:, paths-ignore:) apply
|
|
22
|
+
only to branch-ref pushes. Tag pushes target a refs/tags/* ref, not a refs/heads/* ref, and
|
|
23
|
+
are entirely unaffected by branch filters.
|
|
24
|
+
|
|
25
|
+
When a workflow declares on: push with branches-ignore: but no tags: or tags-ignore: filter,
|
|
26
|
+
all tag pushes trigger the workflow unconditionally regardless of the branch filter.
|
|
27
|
+
|
|
28
|
+
A critical misunderstanding: adding branches-ignore: ['**'] looks like it "disables all push
|
|
29
|
+
triggers" but it only disables branch pushes. Tag pushes still fire unconditionally.
|
|
30
|
+
|
|
31
|
+
GitHub documentation states that push event filters are independent per ref type: branch
|
|
32
|
+
filters only affect refs/heads/* pushes, and tag filters only affect refs/tags/* pushes.
|
|
33
|
+
They do not compose across ref types — setting one does not implicitly filter the other.
|
|
34
|
+
|
|
35
|
+
Consequence: release tag pushes (v1.2.3) trigger CI and CD workflows not designed for them,
|
|
36
|
+
potentially running expensive test suites or deploying artifacts on every version tag.
|
|
37
|
+
This is among the top-voted GitHub Community questions about push event triggers and
|
|
38
|
+
appears repeatedly in Stack Overflow answers on the [github-actions] tag.
|
|
39
|
+
fix: |
|
|
40
|
+
Add an explicit tags-ignore: ['**'] filter to prevent all tag pushes from triggering the
|
|
41
|
+
workflow. Alternatively, use an explicit branches: allowlist — but note that branch
|
|
42
|
+
allowlists also do not suppress tag pushes; tags-ignore: is always required separately.
|
|
43
|
+
|
|
44
|
+
For workflows intended ONLY for tags (release workflows), remove branches filters entirely
|
|
45
|
+
and add tags: with the desired semver glob pattern.
|
|
46
|
+
fix_code:
|
|
47
|
+
- language: yaml
|
|
48
|
+
label: 'Add tags-ignore to explicitly suppress all tag pushes alongside branches-ignore'
|
|
49
|
+
code: |
|
|
50
|
+
on:
|
|
51
|
+
push:
|
|
52
|
+
branches-ignore:
|
|
53
|
+
- 'dependabot/**'
|
|
54
|
+
tags-ignore:
|
|
55
|
+
- '**' # Required — branches-ignore does NOT suppress tag pushes
|
|
56
|
+
- language: yaml
|
|
57
|
+
label: 'Release workflow — run only on semver tags, no branch triggers'
|
|
58
|
+
code: |
|
|
59
|
+
on:
|
|
60
|
+
push:
|
|
61
|
+
tags:
|
|
62
|
+
- 'v[0-9]+.[0-9]+.[0-9]+' # Only fires on semver tags like v1.2.3
|
|
63
|
+
# No branches filter — exclusive tag-only trigger
|
|
64
|
+
prevention:
|
|
65
|
+
- "When adding branches or branches-ignore filters, always decide explicitly whether tag pushes should be included or excluded — then set tags: or tags-ignore: accordingly"
|
|
66
|
+
- 'Use actionlint to validate push trigger filter combinations before committing'
|
|
67
|
+
- 'Document the intent in workflow comments: "This workflow runs on branch pushes only. Tag pushes excluded via tags-ignore."'
|
|
68
|
+
- 'Audit release tag workflows to confirm they use tags: filters rather than relying on implicit gaps in branch filters'
|
|
69
|
+
docs:
|
|
70
|
+
- url: 'https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#push'
|
|
71
|
+
label: 'GitHub Docs: push event — filter pattern cheat sheet'
|
|
72
|
+
- url: 'https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onpushbranchestagsbranches-ignoretags-ignore'
|
|
73
|
+
label: 'GitHub Docs: on.push branches/tags filter syntax'
|
package/package.json
CHANGED