@htekdev/actions-debugger 1.0.45 → 1.0.46
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,70 @@
|
|
|
1
|
+
id: caching-artifacts-034
|
|
2
|
+
title: "Cache entries created in a PR branch are not accessible from other PR branches or the default branch"
|
|
3
|
+
category: caching-artifacts
|
|
4
|
+
severity: limitation
|
|
5
|
+
tags:
|
|
6
|
+
- cache
|
|
7
|
+
- branch-scope
|
|
8
|
+
- pull-request
|
|
9
|
+
- isolation
|
|
10
|
+
- cache-miss
|
|
11
|
+
- known-limitation
|
|
12
|
+
patterns:
|
|
13
|
+
- regex: 'cache.*miss.*pull.request|cache.*not.*found.*branch|cache.*not.*accessible.*pr'
|
|
14
|
+
flags: "i"
|
|
15
|
+
- regex: 'cache.*scope.*branch|branch.specific.*cache.*miss|pr.*branch.*no.*cache'
|
|
16
|
+
flags: "i"
|
|
17
|
+
error_messages:
|
|
18
|
+
- "Cache not found for input keys"
|
|
19
|
+
root_cause: |
|
|
20
|
+
GitHub Actions cache entries are strictly scoped to the branch that created them. The
|
|
21
|
+
cache lookup order during a restore operation is:
|
|
22
|
+
|
|
23
|
+
1. Exact key match on the CURRENT branch
|
|
24
|
+
2. restore-keys prefix match on the CURRENT branch
|
|
25
|
+
3. restore-keys prefix match on the BASE branch (for PRs) or the DEFAULT branch
|
|
26
|
+
|
|
27
|
+
Consequences of this scoping:
|
|
28
|
+
- A cache saved on PR branch A is NOT readable from PR branch B
|
|
29
|
+
- A cache saved on a PR branch is NOT readable from the default branch's push workflow
|
|
30
|
+
- Each new PR starts with a cold cache until it produces its own branch-scoped entry
|
|
31
|
+
- The base branch cache is only available as a fallback during a PR workflow restore
|
|
32
|
+
|
|
33
|
+
This is an intentional security isolation boundary — one PR cannot read potentially
|
|
34
|
+
sensitive build artifacts cached by another PR. There is no configuration option to
|
|
35
|
+
enable cross-PR cache sharing.
|
|
36
|
+
|
|
37
|
+
Teams migrating from shared CI caches (Jenkins, GitLab with shared runner caches) are
|
|
38
|
+
frequently surprised by persistent cache misses across parallel PRs on active repos.
|
|
39
|
+
fix: |
|
|
40
|
+
Structure cache keys and restore-keys to maximize fallback hits from the default branch.
|
|
41
|
+
The strategy: save a well-keyed cache on the default branch after each merge (readable
|
|
42
|
+
by all PRs as a fallback), and include base-branch and OS-only restore-key prefixes so
|
|
43
|
+
new PR runs warm up quickly via partial matches.
|
|
44
|
+
|
|
45
|
+
For dependency caches, a lockfile-hash-keyed entry on main ensures new PRs get a
|
|
46
|
+
near-hit on first run via restore-keys, rather than a completely cold cache.
|
|
47
|
+
fix_code:
|
|
48
|
+
- language: yaml
|
|
49
|
+
label: "Cache key strategy that maximizes default-branch fallback for all PRs"
|
|
50
|
+
code: |
|
|
51
|
+
- name: Cache dependencies
|
|
52
|
+
uses: actions/cache@v4
|
|
53
|
+
with:
|
|
54
|
+
path: ~/.npm
|
|
55
|
+
# Primary: exact branch + lockfile hash (hit on repeat runs of same PR)
|
|
56
|
+
key: ${{ runner.os }}-npm-${{ github.ref_name }}-${{ hashFiles('**/package-lock.json') }}
|
|
57
|
+
# Fallbacks: base branch (for PRs) → default branch → OS-only
|
|
58
|
+
restore-keys: |
|
|
59
|
+
${{ runner.os }}-npm-${{ github.base_ref }}-
|
|
60
|
+
${{ runner.os }}-npm-
|
|
61
|
+
prevention:
|
|
62
|
+
- "Add restore-keys with base branch and OS-only prefixes so PRs fall back to main's cache"
|
|
63
|
+
- "Ensure the default branch workflow saves a fresh cache after each merge so PRs have a warm fallback"
|
|
64
|
+
- "Be aware that parallel PRs each maintain their own independent branch-scoped cache"
|
|
65
|
+
- "For monorepos, include the workspace or package path in the cache key to prevent cross-PR key collisions"
|
|
66
|
+
docs:
|
|
67
|
+
- url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache"
|
|
68
|
+
label: "GitHub Docs: Cache access restrictions by branch"
|
|
69
|
+
- url: "https://github.com/orgs/community/discussions/10539"
|
|
70
|
+
label: "GitHub Community: Cache access is restricted to the same branch and base branches"
|
|
@@ -0,0 +1,87 @@
|
|
|
1
|
+
id: known-unsolved-036
|
|
2
|
+
title: "Scheduled workflows auto-disabled after 60 days of repository inactivity"
|
|
3
|
+
category: known-unsolved
|
|
4
|
+
severity: limitation
|
|
5
|
+
tags:
|
|
6
|
+
- schedule
|
|
7
|
+
- cron
|
|
8
|
+
- inactivity
|
|
9
|
+
- disabled
|
|
10
|
+
- known-limitation
|
|
11
|
+
- maintenance
|
|
12
|
+
patterns:
|
|
13
|
+
- regex: 'This scheduled workflow is disabled|scheduled workflow.*disabled.*no.*activity'
|
|
14
|
+
flags: "i"
|
|
15
|
+
- regex: 'schedule.*60.day.*inactiv|60.day.*no.*activity.*workflow'
|
|
16
|
+
flags: "i"
|
|
17
|
+
error_messages:
|
|
18
|
+
- "This scheduled workflow is disabled because there has been no repository activity in the past 60 days"
|
|
19
|
+
root_cause: |
|
|
20
|
+
GitHub automatically disables on: schedule workflows in repositories that have had no
|
|
21
|
+
activity (pushes, pull requests, merges) for 60 days. This is a platform resource
|
|
22
|
+
management decision to reduce compute on dormant repositories.
|
|
23
|
+
|
|
24
|
+
When triggered, the Actions tab displays a banner:
|
|
25
|
+
"This scheduled workflow is disabled because there has been no repository activity
|
|
26
|
+
in the past 60 days."
|
|
27
|
+
|
|
28
|
+
GitHub sends a notification email before disabling, but many maintainers miss it.
|
|
29
|
+
|
|
30
|
+
Common affected scenarios:
|
|
31
|
+
- Maintenance repos (dependency update jobs, reporting pipelines) with infrequent code changes
|
|
32
|
+
- Scheduled audit or monitoring workflows in stable, rarely-pushed codebases
|
|
33
|
+
- Open source repos that go quiet between releases
|
|
34
|
+
- Returning after extended leave to find weeks or months of scheduled runs silently missed
|
|
35
|
+
|
|
36
|
+
There is no workflow-level setting to prevent automatic disabling. The only remedies
|
|
37
|
+
are to manually re-enable via the GitHub UI or maintain repository activity artificially.
|
|
38
|
+
fix: |
|
|
39
|
+
To re-enable a disabled scheduled workflow:
|
|
40
|
+
1. Navigate to the repository Actions tab
|
|
41
|
+
2. Select the disabled workflow in the left sidebar
|
|
42
|
+
3. Click the "Enable workflow" button shown in the banner
|
|
43
|
+
|
|
44
|
+
To prevent future auto-disabling, add a keep-alive workflow that creates an empty
|
|
45
|
+
commit on a schedule shorter than 60 days. Using stefanzweifel/git-auto-commit-action
|
|
46
|
+
with --allow-empty avoids modifying tracked files while still generating commit activity
|
|
47
|
+
that resets the 60-day counter.
|
|
48
|
+
|
|
49
|
+
There is no REST API endpoint to re-enable disabled scheduled workflows — it must be
|
|
50
|
+
done via the GitHub UI or by pushing a new commit to the repository.
|
|
51
|
+
fix_code:
|
|
52
|
+
- language: yaml
|
|
53
|
+
label: "Keep-alive workflow — runs monthly to prevent schedule auto-disable"
|
|
54
|
+
code: |
|
|
55
|
+
# .github/workflows/keep-alive.yml
|
|
56
|
+
name: Keep Alive
|
|
57
|
+
|
|
58
|
+
on:
|
|
59
|
+
schedule:
|
|
60
|
+
- cron: '0 0 1 * *' # First of each month — well within 60-day window
|
|
61
|
+
workflow_dispatch:
|
|
62
|
+
|
|
63
|
+
jobs:
|
|
64
|
+
keep-alive:
|
|
65
|
+
runs-on: ubuntu-latest
|
|
66
|
+
permissions:
|
|
67
|
+
contents: write
|
|
68
|
+
steps:
|
|
69
|
+
- uses: actions/checkout@v4
|
|
70
|
+
|
|
71
|
+
- name: Maintain repository activity
|
|
72
|
+
uses: stefanzweifel/git-auto-commit-action@v5
|
|
73
|
+
with:
|
|
74
|
+
commit_message: 'chore: keep-alive [skip ci]'
|
|
75
|
+
commit_options: '--allow-empty'
|
|
76
|
+
prevention:
|
|
77
|
+
- "Monitor the Actions tab for the 60-day inactivity warning banner"
|
|
78
|
+
- "Add a keep-alive workflow to all repos with important scheduled jobs but infrequent commits"
|
|
79
|
+
- "Subscribe to GitHub notification emails so the pre-disable warning is not missed"
|
|
80
|
+
- "Document this limitation in the repo CONTRIBUTING guide for future maintainers"
|
|
81
|
+
docs:
|
|
82
|
+
- url: "https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#schedule"
|
|
83
|
+
label: "GitHub Docs: schedule trigger"
|
|
84
|
+
- url: "https://github.com/orgs/community/discussions/5614"
|
|
85
|
+
label: "GitHub Community #5614: Scheduled workflow disabled after 60 days of inactivity"
|
|
86
|
+
- url: "https://github.com/stefanzweifel/git-auto-commit-action"
|
|
87
|
+
label: "stefanzweifel/git-auto-commit-action — keep-alive commit pattern"
|
|
@@ -0,0 +1,93 @@
|
|
|
1
|
+
id: silent-failures-050
|
|
2
|
+
title: "continue-on-error: true on a failing step silently prevents if: failure() downstream steps from running"
|
|
3
|
+
category: silent-failures
|
|
4
|
+
severity: silent-failure
|
|
5
|
+
tags:
|
|
6
|
+
- continue-on-error
|
|
7
|
+
- if-condition
|
|
8
|
+
- failure-check
|
|
9
|
+
- step-outcome
|
|
10
|
+
- silent-skip
|
|
11
|
+
- cleanup
|
|
12
|
+
patterns:
|
|
13
|
+
- regex: 'continue.on.error.*if.*failure|if.*failure.*not.*running.*continue.on.error'
|
|
14
|
+
flags: "i"
|
|
15
|
+
- regex: 'cleanup.*step.*skipped.*continue.on.error|failure.*handler.*not.*triggered'
|
|
16
|
+
flags: "i"
|
|
17
|
+
error_messages:
|
|
18
|
+
- "Downstream step with if: failure() silently skipped when preceding step uses continue-on-error: true"
|
|
19
|
+
root_cause: |
|
|
20
|
+
When a step fails AND has continue-on-error: true, GitHub Actions marks that step's
|
|
21
|
+
conclusion as success (the error was absorbed) while preserving its outcome as failure.
|
|
22
|
+
Because the step conclusion is success, the job's overall result remains success.
|
|
23
|
+
|
|
24
|
+
Any downstream step or job conditioned on if: failure() evaluates the job's overall
|
|
25
|
+
status, not individual step outcomes. Since the job is still succeeding (the failure was
|
|
26
|
+
continued past), if: failure() evaluates to false — and those downstream steps are
|
|
27
|
+
silently skipped with no error or warning.
|
|
28
|
+
|
|
29
|
+
The pattern developers expect to work (but doesn't):
|
|
30
|
+
|
|
31
|
+
steps:
|
|
32
|
+
- name: Run tests
|
|
33
|
+
run: npm test
|
|
34
|
+
continue-on-error: true
|
|
35
|
+
- name: Upload failure report # NEVER runs — job outcome is still 'success'
|
|
36
|
+
if: failure()
|
|
37
|
+
|
|
38
|
+
Silently broken patterns:
|
|
39
|
+
- Failure notification steps after continue-on-error test or lint steps
|
|
40
|
+
- Cleanup steps conditioned on job failure after a continued-on-error build
|
|
41
|
+
- Report upload or artifact save steps expected to fire when tests fail
|
|
42
|
+
- Alerting steps (Slack, PagerDuty) conditioned on failure() after a tolerated failure
|
|
43
|
+
fix: |
|
|
44
|
+
Reference the specific failing step's outcome directly using steps.<id>.outcome
|
|
45
|
+
instead of the job-level failure() function. Give the step-with-continue-on-error an
|
|
46
|
+
explicit id: field, then condition the downstream step on
|
|
47
|
+
steps.<step-id>.outcome == 'failure'.
|
|
48
|
+
|
|
49
|
+
This correctly captures the step-level failure even when the job overall is succeeding.
|
|
50
|
+
fix_code:
|
|
51
|
+
- language: yaml
|
|
52
|
+
label: "Wrong: if: failure() silently never fires after a continue-on-error step"
|
|
53
|
+
code: |
|
|
54
|
+
steps:
|
|
55
|
+
- name: Run tests
|
|
56
|
+
run: npm test
|
|
57
|
+
continue-on-error: true
|
|
58
|
+
# Job outcome stays 'success' — if: failure() below never executes
|
|
59
|
+
|
|
60
|
+
- name: Upload test failure report
|
|
61
|
+
if: failure()
|
|
62
|
+
uses: actions/upload-artifact@v4
|
|
63
|
+
with:
|
|
64
|
+
name: test-report
|
|
65
|
+
path: test-results/
|
|
66
|
+
- language: yaml
|
|
67
|
+
label: "Correct: check the specific step outcome to catch the continued failure"
|
|
68
|
+
code: |
|
|
69
|
+
steps:
|
|
70
|
+
- name: Run tests
|
|
71
|
+
id: run-tests # Explicit ID required to reference outcome below
|
|
72
|
+
run: npm test
|
|
73
|
+
continue-on-error: true
|
|
74
|
+
|
|
75
|
+
- name: Upload test failure report
|
|
76
|
+
# Fires when tests failed — works correctly even though the job is still 'success'
|
|
77
|
+
if: steps.run-tests.outcome == 'failure'
|
|
78
|
+
uses: actions/upload-artifact@v4
|
|
79
|
+
with:
|
|
80
|
+
name: test-report
|
|
81
|
+
path: test-results/
|
|
82
|
+
prevention:
|
|
83
|
+
- "Never rely on if: failure() to detect failures from steps that use continue-on-error: true"
|
|
84
|
+
- "Assign explicit id: to any step with continue-on-error that needs downstream conditional checks"
|
|
85
|
+
- "Use steps.<id>.outcome == 'failure' to condition steps on a specific earlier step's result"
|
|
86
|
+
- "Test failure-handler steps explicitly by temporarily forcing the upstream step to fail without continue-on-error"
|
|
87
|
+
docs:
|
|
88
|
+
- url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/using-conditions-to-control-job-execution"
|
|
89
|
+
label: "GitHub Docs: Using conditions to control job execution"
|
|
90
|
+
- url: "https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#steps-context"
|
|
91
|
+
label: "GitHub Docs: steps context — outcome vs conclusion"
|
|
92
|
+
- url: "https://github.com/orgs/community/discussions/25420"
|
|
93
|
+
label: "GitHub Community: continue-on-error and if: failure() interaction explained"
|
|
@@ -0,0 +1,100 @@
|
|
|
1
|
+
id: triggers-033
|
|
2
|
+
title: "Commits, PRs, and releases created using GITHUB_TOKEN do not trigger new workflow runs"
|
|
3
|
+
category: triggers
|
|
4
|
+
severity: limitation
|
|
5
|
+
tags:
|
|
6
|
+
- GITHUB_TOKEN
|
|
7
|
+
- loopback-prevention
|
|
8
|
+
- push-event
|
|
9
|
+
- pull-request
|
|
10
|
+
- no-trigger
|
|
11
|
+
- known-limitation
|
|
12
|
+
patterns:
|
|
13
|
+
- regex: 'GITHUB_TOKEN.*push.*not.*trigger|workflow.*not.*triggered.*after.*commit'
|
|
14
|
+
flags: "i"
|
|
15
|
+
- regex: 'auto.commit.*no.*workflow|push.*token.*not.*firing.*CI'
|
|
16
|
+
flags: "i"
|
|
17
|
+
error_messages:
|
|
18
|
+
- "Workflow not triggered after automated push using GITHUB_TOKEN"
|
|
19
|
+
root_cause: |
|
|
20
|
+
GitHub Actions intentionally prevents new workflow runs from being triggered by events
|
|
21
|
+
performed with the built-in GITHUB_TOKEN. This loopback prevention exists to stop
|
|
22
|
+
accidental or malicious infinite workflow loops — for example, a push workflow that
|
|
23
|
+
commits back to the repo and re-triggers itself in perpetuity.
|
|
24
|
+
|
|
25
|
+
Affected operations when performed with GITHUB_TOKEN:
|
|
26
|
+
- Pushing a commit to a branch (no push event fired; CI does not run on the new SHA)
|
|
27
|
+
- Creating a pull request via REST API (no pull_request event fired; PR checks do not start)
|
|
28
|
+
- Publishing a release (no release event fired)
|
|
29
|
+
- Merging a PR programmatically (no push or pull_request closed event fired)
|
|
30
|
+
|
|
31
|
+
Common surprise scenarios:
|
|
32
|
+
- Auto-version-bump workflows that commit package.json and expect CI to run on the result
|
|
33
|
+
- Automated changelog commits that should trigger a docs publish pipeline
|
|
34
|
+
- Bots that open PRs using GITHUB_TOKEN expecting branch protection checks to start
|
|
35
|
+
- Tag-from-workflow jobs expecting the resulting tag push to start a release pipeline
|
|
36
|
+
fix: |
|
|
37
|
+
To trigger new workflow runs from operations performed inside a workflow, use a Personal
|
|
38
|
+
Access Token (PAT) or a GitHub App installation token instead of GITHUB_TOKEN. Events
|
|
39
|
+
created with these tokens are not subject to the loopback prevention rule.
|
|
40
|
+
|
|
41
|
+
For organizational workflows, GitHub App tokens are the recommended approach — they
|
|
42
|
+
do not rely on a personal user's credentials and can be scoped to minimum permissions.
|
|
43
|
+
|
|
44
|
+
If triggering new runs is NOT needed, add [skip ci] to the commit message to make the
|
|
45
|
+
intent explicit and prevent accidental CI consumption if a PAT is used later.
|
|
46
|
+
fix_code:
|
|
47
|
+
- language: yaml
|
|
48
|
+
label: "PAT-based checkout so the resulting push triggers downstream CI"
|
|
49
|
+
code: |
|
|
50
|
+
jobs:
|
|
51
|
+
version-bump:
|
|
52
|
+
runs-on: ubuntu-latest
|
|
53
|
+
steps:
|
|
54
|
+
# Check out with PAT — any subsequent push WILL trigger a new push workflow run
|
|
55
|
+
- uses: actions/checkout@v4
|
|
56
|
+
with:
|
|
57
|
+
token: ${{ secrets.MY_PAT }}
|
|
58
|
+
|
|
59
|
+
- name: Bump version
|
|
60
|
+
run: npm version patch --no-git-tag-version
|
|
61
|
+
|
|
62
|
+
- name: Commit and push version bump
|
|
63
|
+
uses: stefanzweifel/git-auto-commit-action@v5
|
|
64
|
+
with:
|
|
65
|
+
commit_message: 'chore: bump version'
|
|
66
|
+
- language: yaml
|
|
67
|
+
label: "GitHub App token so an auto-created PR triggers branch protection checks"
|
|
68
|
+
code: |
|
|
69
|
+
jobs:
|
|
70
|
+
create-pr:
|
|
71
|
+
runs-on: ubuntu-latest
|
|
72
|
+
steps:
|
|
73
|
+
- name: Get GitHub App token
|
|
74
|
+
id: app-token
|
|
75
|
+
uses: actions/create-github-app-token@v1
|
|
76
|
+
with:
|
|
77
|
+
app-id: ${{ secrets.APP_ID }}
|
|
78
|
+
private-key: ${{ secrets.APP_PRIVATE_KEY }}
|
|
79
|
+
|
|
80
|
+
- uses: actions/checkout@v4
|
|
81
|
+
with:
|
|
82
|
+
token: ${{ steps.app-token.outputs.token }}
|
|
83
|
+
|
|
84
|
+
- name: Create PR — App token causes PR checks to be triggered
|
|
85
|
+
uses: peter-evans/create-pull-request@v6
|
|
86
|
+
with:
|
|
87
|
+
token: ${{ steps.app-token.outputs.token }}
|
|
88
|
+
title: 'chore: automated update'
|
|
89
|
+
prevention:
|
|
90
|
+
- "Use a PAT or GitHub App token when downstream workflow runs must be triggered by a commit or PR"
|
|
91
|
+
- "Add [skip ci] to auto-commit messages when downstream CI triggering is explicitly NOT needed"
|
|
92
|
+
- "Document in workflow comments why PAT or App token is used instead of GITHUB_TOKEN"
|
|
93
|
+
- "When debugging missing CI runs after automated commits, check whether GITHUB_TOKEN loopback prevention applies"
|
|
94
|
+
docs:
|
|
95
|
+
- url: "https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#using-the-github_token-in-a-workflow"
|
|
96
|
+
label: "GitHub Docs: Automatic token authentication — events triggered by GITHUB_TOKEN"
|
|
97
|
+
- url: "https://github.com/orgs/community/discussions/27072"
|
|
98
|
+
label: "GitHub Community: Push with GITHUB_TOKEN does not trigger new workflow runs"
|
|
99
|
+
- url: "https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow"
|
|
100
|
+
label: "GitHub Docs: Using a GitHub App token in Actions workflows"
|
package/package.json
CHANGED