@htekdev/actions-debugger 1.0.49 → 1.0.50
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,119 @@
|
|
|
1
|
+
id: caching-artifacts-035
|
|
2
|
+
title: 'actions/cache fail-on-cache-miss: true causes first-run workflow failure — no cache exists on initial or rekeyed run'
|
|
3
|
+
category: caching-artifacts
|
|
4
|
+
severity: error
|
|
5
|
+
tags:
|
|
6
|
+
- cache
|
|
7
|
+
- fail-on-cache-miss
|
|
8
|
+
- first-run
|
|
9
|
+
- actions-cache
|
|
10
|
+
- cache-miss
|
|
11
|
+
- bootstrap
|
|
12
|
+
patterns:
|
|
13
|
+
- regex: 'fail-on-cache-miss:\s*true'
|
|
14
|
+
flags: 'i'
|
|
15
|
+
- regex: 'Error: Cannot find a cache that matches the specified keys'
|
|
16
|
+
flags: 'i'
|
|
17
|
+
error_messages:
|
|
18
|
+
- 'Error: Cannot find a cache that matches the specified keys'
|
|
19
|
+
- 'Cache not found for input keys: ...'
|
|
20
|
+
- '##[error]Cannot find a cache that matches the specified keys'
|
|
21
|
+
root_cause: |
|
|
22
|
+
The actions/cache action added a fail-on-cache-miss input (introduced in v3.3.0,
|
|
23
|
+
available in v4). When set to true, the action exits with a non-zero status code
|
|
24
|
+
if no cache entry matches the provided key or restore-keys list. The intended use
|
|
25
|
+
case is detecting stale or misconfigured cache keys in established pipelines.
|
|
26
|
+
|
|
27
|
+
The critical problem: on the very first run of a workflow (new repository, newly
|
|
28
|
+
added cache step, or after changing the cache key expression), NO cache exists by
|
|
29
|
+
definition. With fail-on-cache-miss: true, the action fails immediately and the
|
|
30
|
+
job exits before any steps produce the artifacts that would be cached.
|
|
31
|
+
|
|
32
|
+
This creates a bootstrap deadlock:
|
|
33
|
+
1. Job starts — no cache exists — fail-on-cache-miss: true fires — job fails
|
|
34
|
+
2. Post-step cache save never runs because the job failed
|
|
35
|
+
3. Next run repeats step 1 — cache is never populated — workflow is permanently broken
|
|
36
|
+
|
|
37
|
+
The same issue occurs whenever the cache key expression changes (adding runner OS,
|
|
38
|
+
changing the hash source file, bumping a version prefix), because all existing
|
|
39
|
+
caches miss the new key pattern. Until the new cache is warm, every run fails.
|
|
40
|
+
|
|
41
|
+
Matrix builds compound the problem: each unique matrix dimension (OS × version)
|
|
42
|
+
needs its own initial run to seed the cache, so all combinations fail in parallel
|
|
43
|
+
on first use of the new key.
|
|
44
|
+
fix: |
|
|
45
|
+
Remove fail-on-cache-miss: true from the actions/cache step unless you have an
|
|
46
|
+
externally pre-seeded cache and a specific requirement to guarantee it exists
|
|
47
|
+
(rare, advanced use case).
|
|
48
|
+
|
|
49
|
+
For the common use case of skipping expensive install steps on cache hit:
|
|
50
|
+
use the cache-hit output instead. cache-hit is 'true' on exact key match and
|
|
51
|
+
allows downstream steps to be conditional, while still letting the job complete
|
|
52
|
+
successfully on a miss so the cache can be populated.
|
|
53
|
+
|
|
54
|
+
If you genuinely need to gate on cache existence (e.g., a nightly build that
|
|
55
|
+
consumes a separately-seeded model or dataset cache), run a dedicated cache-warming
|
|
56
|
+
workflow first and use fail-on-cache-miss: true only after confirming the seeder
|
|
57
|
+
workflow has run at least once.
|
|
58
|
+
fix_code:
|
|
59
|
+
- language: yaml
|
|
60
|
+
label: 'Use cache-hit output for conditional install instead of fail-on-cache-miss'
|
|
61
|
+
code: |
|
|
62
|
+
jobs:
|
|
63
|
+
build:
|
|
64
|
+
runs-on: ubuntu-latest
|
|
65
|
+
steps:
|
|
66
|
+
- uses: actions/checkout@v4
|
|
67
|
+
|
|
68
|
+
- name: Cache npm dependencies
|
|
69
|
+
id: cache-npm
|
|
70
|
+
uses: actions/cache@v4
|
|
71
|
+
with:
|
|
72
|
+
path: ~/.npm
|
|
73
|
+
key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
|
|
74
|
+
restore-keys: |
|
|
75
|
+
${{ runner.os }}-npm-
|
|
76
|
+
# AVOID: fail-on-cache-miss: true ← breaks first run (deadlock)
|
|
77
|
+
|
|
78
|
+
- name: Install dependencies
|
|
79
|
+
# Only runs on cache miss — fast path skipped on hit
|
|
80
|
+
if: steps.cache-npm.outputs.cache-hit != 'true'
|
|
81
|
+
run: npm ci
|
|
82
|
+
|
|
83
|
+
- name: Build
|
|
84
|
+
run: npm run build
|
|
85
|
+
|
|
86
|
+
- language: yaml
|
|
87
|
+
label: 'Dedicated cache-warming workflow to pre-seed before fail-on-cache-miss use'
|
|
88
|
+
code: |
|
|
89
|
+
# .github/workflows/warm-cache.yml — run this first to pre-seed
|
|
90
|
+
name: Warm Cache
|
|
91
|
+
on:
|
|
92
|
+
schedule:
|
|
93
|
+
- cron: '0 6 * * 1'
|
|
94
|
+
workflow_dispatch: # Allow manual trigger when rekeying cache
|
|
95
|
+
|
|
96
|
+
jobs:
|
|
97
|
+
warm:
|
|
98
|
+
runs-on: ubuntu-latest
|
|
99
|
+
steps:
|
|
100
|
+
- uses: actions/checkout@v4
|
|
101
|
+
- name: Cache dependencies
|
|
102
|
+
uses: actions/cache@v4
|
|
103
|
+
with:
|
|
104
|
+
path: ~/.npm
|
|
105
|
+
key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
|
|
106
|
+
- name: Install to populate cache
|
|
107
|
+
run: npm ci
|
|
108
|
+
prevention:
|
|
109
|
+
- 'Never set fail-on-cache-miss: true on a fresh workflow or after changing the cache key expression — the cache cannot exist yet'
|
|
110
|
+
- 'Use cache-hit output and conditional if: steps.id.outputs.cache-hit != true for skip-on-hit behavior without failing on miss'
|
|
111
|
+
- 'When rekeying cache (OS prefix, hash source change), trigger a manual cache-warming workflow_dispatch run before deploying the new key'
|
|
112
|
+
- 'Test new cache key expressions in a feature branch where a job failure will not block main'
|
|
113
|
+
docs:
|
|
114
|
+
- url: 'https://github.com/actions/cache'
|
|
115
|
+
label: 'actions/cache README — fail-on-cache-miss input documentation'
|
|
116
|
+
- url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows'
|
|
117
|
+
label: 'GitHub Docs: Caching dependencies to speed up workflows'
|
|
118
|
+
- url: 'https://github.com/actions/cache/blob/main/tips-and-workarounds.md'
|
|
119
|
+
label: 'actions/cache tips and workarounds — cache miss handling patterns'
|
|
@@ -0,0 +1,111 @@
|
|
|
1
|
+
id: runner-environment-105
|
|
2
|
+
title: 'macOS 12 (Monterey) runner retired September 2024 — runs-on: macos-12 workflows fail or queue indefinitely'
|
|
3
|
+
category: runner-environment
|
|
4
|
+
severity: error
|
|
5
|
+
tags:
|
|
6
|
+
- macos-12
|
|
7
|
+
- runner-retirement
|
|
8
|
+
- macos-monterey
|
|
9
|
+
- deprecated-runner
|
|
10
|
+
- github-hosted
|
|
11
|
+
- runs-on
|
|
12
|
+
patterns:
|
|
13
|
+
- regex: 'runs-on:\s*macos-12'
|
|
14
|
+
flags: 'i'
|
|
15
|
+
- regex: 'No runner matching the specified labels was found.*macos-12|Requested labels: macos-12'
|
|
16
|
+
flags: 'i'
|
|
17
|
+
error_messages:
|
|
18
|
+
- 'No runner matching the specified labels was found: macos-12'
|
|
19
|
+
- '##[error]No runner matching the specified labels was found'
|
|
20
|
+
- 'Runner not found matching labels: [macos-12]'
|
|
21
|
+
root_cause: |
|
|
22
|
+
GitHub retired the macOS 12 (Monterey) hosted runner on September 1, 2024. After
|
|
23
|
+
this date, workflows specifying runs-on: macos-12 can no longer be scheduled on a
|
|
24
|
+
GitHub-hosted runner matching that label.
|
|
25
|
+
|
|
26
|
+
Depending on repository and organization settings, affected jobs may:
|
|
27
|
+
- Fail immediately with "No runner matching the specified labels was found"
|
|
28
|
+
- Queue indefinitely waiting for a runner that will never be provisioned
|
|
29
|
+
- Show a "This job was skipped" status with no clear error message
|
|
30
|
+
|
|
31
|
+
GitHub announced the deprecation on May 20, 2024 (90+ days notice) and made it
|
|
32
|
+
official with a deprecation flag on July 1, 2024. Hard retirement occurred
|
|
33
|
+
September 1, 2024.
|
|
34
|
+
|
|
35
|
+
macOS 12 was the Monterey release. GitHub's macOS runner fleet moved to:
|
|
36
|
+
- macOS 13 (Ventura) — Intel x86-64, became the Intel baseline
|
|
37
|
+
- macOS 14 (Sonoma) — Apple Silicon M1, new default for macos-latest (Oct 2024)
|
|
38
|
+
- macOS 15 (Sequoia) — Apple Silicon M2, macos-latest as of January 2025
|
|
39
|
+
|
|
40
|
+
Common sources of this error after retirement:
|
|
41
|
+
- Long-lived workflow files written when macOS 12 was current
|
|
42
|
+
- Forks and template repositories with outdated runner labels
|
|
43
|
+
- Composite actions that pin macos-12 in their action.yml runs: block
|
|
44
|
+
- Third-party reusable workflows that have not been updated
|
|
45
|
+
fix: |
|
|
46
|
+
Replace runs-on: macos-12 with a supported macOS runner label. Choose based on
|
|
47
|
+
architecture requirements:
|
|
48
|
+
|
|
49
|
+
- macos-13 — Intel x86-64, macOS Ventura (closest to macOS 12 behavior)
|
|
50
|
+
- macos-14 — Apple Silicon M1, macOS Sonoma
|
|
51
|
+
- macos-15 — Apple Silicon M2, macOS Sequoia
|
|
52
|
+
- macos-latest — currently macOS 15 / Apple Silicon as of January 2025
|
|
53
|
+
|
|
54
|
+
IMPORTANT: macos-14 and later use Apple Silicon (M1/M2). If your workflow depends
|
|
55
|
+
on Intel x86-64 architecture (Homebrew formula paths differ, Rosetta 2 needed for
|
|
56
|
+
old binaries, or x86-specific compiler flags), migrate to macos-13, not macos-latest.
|
|
57
|
+
|
|
58
|
+
After migrating, verify:
|
|
59
|
+
- Homebrew default prefix changed from /usr/local (Intel) to /opt/homebrew (ARM)
|
|
60
|
+
- Xcode version availability — use actions/setup-xcode for explicit version pinning
|
|
61
|
+
- System Python and Ruby versions differ between macOS generations
|
|
62
|
+
- Any hardcoded SDKROOT or architecture flags targeting x86-64
|
|
63
|
+
fix_code:
|
|
64
|
+
- language: yaml
|
|
65
|
+
label: 'Replace retired macos-12 with macos-13 (Intel) or macos-14/15 (Apple Silicon)'
|
|
66
|
+
code: |
|
|
67
|
+
jobs:
|
|
68
|
+
build-intel:
|
|
69
|
+
# Before: runs-on: macos-12 ← retired September 1, 2024
|
|
70
|
+
# Intel x86-64 — closest behavioral match to macOS 12:
|
|
71
|
+
runs-on: macos-13
|
|
72
|
+
steps:
|
|
73
|
+
- uses: actions/checkout@v4
|
|
74
|
+
- name: Build
|
|
75
|
+
run: make build
|
|
76
|
+
|
|
77
|
+
build-arm:
|
|
78
|
+
# Apple Silicon M1/M2 — use for new projects or ARM-compatible builds:
|
|
79
|
+
runs-on: macos-latest # macOS 15 / Apple Silicon as of Jan 2025
|
|
80
|
+
steps:
|
|
81
|
+
- uses: actions/checkout@v4
|
|
82
|
+
- name: Build
|
|
83
|
+
run: make build
|
|
84
|
+
|
|
85
|
+
- language: yaml
|
|
86
|
+
label: 'Matrix across macOS versions to validate compatibility before committing to one'
|
|
87
|
+
code: |
|
|
88
|
+
jobs:
|
|
89
|
+
test:
|
|
90
|
+
strategy:
|
|
91
|
+
matrix:
|
|
92
|
+
# Test Intel (13) and Apple Silicon (14) in parallel
|
|
93
|
+
os: [macos-13, macos-14]
|
|
94
|
+
fail-fast: false
|
|
95
|
+
runs-on: ${{ matrix.os }}
|
|
96
|
+
steps:
|
|
97
|
+
- uses: actions/checkout@v4
|
|
98
|
+
- name: Test on ${{ matrix.os }}
|
|
99
|
+
run: make test
|
|
100
|
+
prevention:
|
|
101
|
+
- 'Subscribe to the GitHub Changelog (github.blog/changelog) for runner retirement notices — typically 90+ days notice'
|
|
102
|
+
- 'Pin to a specific macOS version (macos-13, macos-14) rather than macos-latest for reproducible builds; macos-latest advances'
|
|
103
|
+
- 'Be aware of architecture differences: macos-13 is Intel x86-64; macos-14 and later are Apple Silicon'
|
|
104
|
+
- 'Search workflow files periodically for retired labels: look for macos-12, macos-11, ubuntu-18.04, windows-2019'
|
|
105
|
+
docs:
|
|
106
|
+
- url: 'https://github.blog/changelog/2024-05-20-actions-upcoming-changes-to-github-hosted-macos-runners/'
|
|
107
|
+
label: 'GitHub Changelog: Upcoming changes to macOS runners (May 2024)'
|
|
108
|
+
- url: 'https://github.blog/changelog/2024-07-01-github-actions-macos-12-is-now-deprecated/'
|
|
109
|
+
label: 'GitHub Changelog: macOS 12 is now deprecated (July 2024)'
|
|
110
|
+
- url: 'https://docs.github.com/en/actions/using-github-hosted-runners/using-github-hosted-runners/about-github-hosted-runners#supported-runners-and-hardware-resources'
|
|
111
|
+
label: 'GitHub Docs: Supported runners and hardware resources'
|
|
@@ -0,0 +1,126 @@
|
|
|
1
|
+
id: triggers-038
|
|
2
|
+
title: 'workflow_run.conclusion is null when the upstream run was cancelled before any job started — if: checks silently skip'
|
|
3
|
+
category: triggers
|
|
4
|
+
severity: silent-failure
|
|
5
|
+
tags:
|
|
6
|
+
- workflow-run
|
|
7
|
+
- conclusion
|
|
8
|
+
- cancelled
|
|
9
|
+
- null-conclusion
|
|
10
|
+
- if-condition
|
|
11
|
+
- cross-workflow
|
|
12
|
+
patterns:
|
|
13
|
+
- regex: 'github\.event\.workflow_run\.conclusion\s*==\s*[''"]success[''"]'
|
|
14
|
+
flags: 'i'
|
|
15
|
+
- regex: 'github\.event\.workflow_run\.conclusion\s*==\s*[''"]failure[''"]'
|
|
16
|
+
flags: 'i'
|
|
17
|
+
error_messages:
|
|
18
|
+
- "(No error — triggered workflow runs but all jobs/steps with if: github.event.workflow_run.conclusion == 'success' silently skip)"
|
|
19
|
+
root_cause: |
|
|
20
|
+
When a downstream workflow uses on: workflow_run (types: [completed]), it fires
|
|
21
|
+
whenever an upstream workflow run reaches a terminal state. The
|
|
22
|
+
github.event.workflow_run.conclusion field is expected to reflect the outcome of
|
|
23
|
+
that upstream run.
|
|
24
|
+
|
|
25
|
+
However, if the upstream run was cancelled before any job started — for example,
|
|
26
|
+
due to a concurrent push triggering cancel-in-progress on the queued run, or a
|
|
27
|
+
manual UI cancellation before the run left the queue — the conclusion field is
|
|
28
|
+
null, not "cancelled".
|
|
29
|
+
|
|
30
|
+
GitHub's API returns: { "conclusion": null, "status": "cancelled" } for runs
|
|
31
|
+
cancelled while still queued. This is documented behavior: conclusion is only set
|
|
32
|
+
when at least one job has run to completion.
|
|
33
|
+
|
|
34
|
+
The effect on downstream conditional logic:
|
|
35
|
+
if: github.event.workflow_run.conclusion == 'success' → false (null != string)
|
|
36
|
+
if: github.event.workflow_run.conclusion == 'failure' → false
|
|
37
|
+
if: github.event.workflow_run.conclusion == 'cancelled' → also false (null != string)
|
|
38
|
+
if: github.event.workflow_run.conclusion != 'success' → TRUE (null != string)
|
|
39
|
+
|
|
40
|
+
The downstream workflow's workflow_run completed event fires and the workflow
|
|
41
|
+
starts, but every job with a success/failure/cancelled equality check is silently
|
|
42
|
+
skipped. A CD pipeline gated on CI success may appear to trigger but produce no
|
|
43
|
+
deployment with no error surfaced to the developer.
|
|
44
|
+
|
|
45
|
+
This can also silently allow deployment jobs protected by
|
|
46
|
+
conclusion != 'failure' to run when the upstream was an early cancellation.
|
|
47
|
+
fix: |
|
|
48
|
+
Treat workflow_run.conclusion as nullable. Always verify it is not null before
|
|
49
|
+
comparing to an expected value:
|
|
50
|
+
|
|
51
|
+
Option A — Explicit null check (most readable):
|
|
52
|
+
if: github.event.workflow_run.conclusion != null && github.event.workflow_run.conclusion == 'success'
|
|
53
|
+
|
|
54
|
+
Option B — contains() with fromJSON allowlist (handles null gracefully; null is
|
|
55
|
+
not in the list, so the condition evaluates false without error):
|
|
56
|
+
if: contains(fromJSON('["success"]'), github.event.workflow_run.conclusion)
|
|
57
|
+
|
|
58
|
+
Option C — Guard step that fails fast and visibly when conclusion is unexpected,
|
|
59
|
+
so silent skips become explicit failures:
|
|
60
|
+
- run: |
|
|
61
|
+
if [ "$CONCLUSION" != "success" ]; then
|
|
62
|
+
echo "Upstream conclusion was: $CONCLUSION"
|
|
63
|
+
exit 1
|
|
64
|
+
fi
|
|
65
|
+
env:
|
|
66
|
+
CONCLUSION: ${{ github.event.workflow_run.conclusion }}
|
|
67
|
+
fix_code:
|
|
68
|
+
- language: yaml
|
|
69
|
+
label: 'Use contains() with fromJSON to handle null conclusion safely'
|
|
70
|
+
code: |
|
|
71
|
+
on:
|
|
72
|
+
workflow_run:
|
|
73
|
+
workflows: ['CI']
|
|
74
|
+
types: [completed]
|
|
75
|
+
|
|
76
|
+
jobs:
|
|
77
|
+
deploy:
|
|
78
|
+
# contains() returns false when conclusion is null — no null-equality error
|
|
79
|
+
if: |
|
|
80
|
+
contains(fromJSON('["success"]'), github.event.workflow_run.conclusion) &&
|
|
81
|
+
github.event.workflow_run.head_branch == 'main'
|
|
82
|
+
runs-on: ubuntu-latest
|
|
83
|
+
steps:
|
|
84
|
+
- name: Deploy
|
|
85
|
+
run: echo "Deploying after confirmed CI success"
|
|
86
|
+
|
|
87
|
+
- language: yaml
|
|
88
|
+
label: 'Guard step that fails visibly on null or unexpected conclusion'
|
|
89
|
+
code: |
|
|
90
|
+
on:
|
|
91
|
+
workflow_run:
|
|
92
|
+
workflows: ['CI']
|
|
93
|
+
types: [completed]
|
|
94
|
+
|
|
95
|
+
jobs:
|
|
96
|
+
verify-conclusion:
|
|
97
|
+
runs-on: ubuntu-latest
|
|
98
|
+
steps:
|
|
99
|
+
- name: Check upstream conclusion
|
|
100
|
+
env:
|
|
101
|
+
CONCLUSION: ${{ github.event.workflow_run.conclusion }}
|
|
102
|
+
run: |
|
|
103
|
+
echo "Upstream workflow conclusion: $CONCLUSION"
|
|
104
|
+
if [ "$CONCLUSION" != "success" ]; then
|
|
105
|
+
echo "Expected 'success', got '$CONCLUSION' (possibly null if cancelled before job start)"
|
|
106
|
+
exit 1
|
|
107
|
+
fi
|
|
108
|
+
|
|
109
|
+
deploy:
|
|
110
|
+
needs: verify-conclusion
|
|
111
|
+
runs-on: ubuntu-latest
|
|
112
|
+
steps:
|
|
113
|
+
- name: Deploy
|
|
114
|
+
run: echo "Deploying"
|
|
115
|
+
prevention:
|
|
116
|
+
- 'Always treat workflow_run.conclusion as nullable — a run cancelled while queued has conclusion: null, not "cancelled"'
|
|
117
|
+
- 'Use contains(fromJSON(...), github.event.workflow_run.conclusion) instead of == equality — contains() handles null safely'
|
|
118
|
+
- 'Add a guard step that prints the actual conclusion value to make silent skips visible during debugging'
|
|
119
|
+
- 'Prefer repository_dispatch for cross-workflow chaining when you need explicit control over the payload and conclusion semantics'
|
|
120
|
+
docs:
|
|
121
|
+
- url: 'https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#workflow_run'
|
|
122
|
+
label: 'GitHub Docs: workflow_run event — conclusion field behavior'
|
|
123
|
+
- url: 'https://docs.github.com/en/rest/actions/workflow-runs?apiVersion=2022-11-28#get-a-workflow-run'
|
|
124
|
+
label: 'GitHub REST API: Workflow run — conclusion is nullable'
|
|
125
|
+
- url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/contexts#github-context'
|
|
126
|
+
label: 'GitHub Docs: github.event.workflow_run context properties'
|
|
@@ -0,0 +1,100 @@
|
|
|
1
|
+
id: yaml-syntax-036
|
|
2
|
+
title: 'run-name: using github.event.head_commit.message shows "undefined" for schedule and workflow_dispatch events'
|
|
3
|
+
category: yaml-syntax
|
|
4
|
+
severity: warning
|
|
5
|
+
tags:
|
|
6
|
+
- run-name
|
|
7
|
+
- head-commit-message
|
|
8
|
+
- schedule
|
|
9
|
+
- workflow-dispatch
|
|
10
|
+
- null-property
|
|
11
|
+
- expression
|
|
12
|
+
patterns:
|
|
13
|
+
- regex: 'run-name:.*head_commit\.message'
|
|
14
|
+
flags: 'i'
|
|
15
|
+
error_messages:
|
|
16
|
+
- "(Run title in the UI displays 'undefined' or 'Deploy by @actor from undefined' — no log error is emitted)"
|
|
17
|
+
root_cause: |
|
|
18
|
+
The run-name: workflow key (introduced October 2022) lets you set a custom title
|
|
19
|
+
for each workflow run using GitHub Actions expressions. The GitHub Docs examples
|
|
20
|
+
include the pattern:
|
|
21
|
+
|
|
22
|
+
run-name: Deploy by @${{ github.actor }} from ${{ github.event.head_commit.message }}
|
|
23
|
+
|
|
24
|
+
However, github.event.head_commit is ONLY populated for on: push events. For
|
|
25
|
+
on: schedule, on: workflow_dispatch, on: pull_request, on: release, and most other
|
|
26
|
+
event types, the head_commit object is absent from the event payload. Accessing
|
|
27
|
+
github.event.head_commit.message on a null object evaluates to '' in some contexts
|
|
28
|
+
but renders as "undefined" in the Actions UI run title.
|
|
29
|
+
|
|
30
|
+
The result is a workflow run title like:
|
|
31
|
+
"Deploy by @octocat from undefined"
|
|
32
|
+
or simply "undefined" — confusing in the Actions tab and audit logs.
|
|
33
|
+
|
|
34
|
+
The workflow parses without error because the expression is syntactically valid.
|
|
35
|
+
The problem only surfaces at runtime when a non-push event triggers the workflow.
|
|
36
|
+
This is especially common in workflows that have both on: push and on: schedule or
|
|
37
|
+
on: workflow_dispatch triggers.
|
|
38
|
+
fix: |
|
|
39
|
+
Use the || short-circuit operator to provide fallback values for event types where
|
|
40
|
+
head_commit is absent. GitHub Actions expressions treat || as a null/false fallback:
|
|
41
|
+
|
|
42
|
+
run-name: "${{ github.event.head_commit.message || github.event.inputs.reason || 'Scheduled run' }}"
|
|
43
|
+
|
|
44
|
+
Prefer contexts that are populated for ALL event types:
|
|
45
|
+
- github.actor — always set (the user or app that triggered the run)
|
|
46
|
+
- github.ref_name — always set (branch or tag short name)
|
|
47
|
+
- github.run_number — always set (monotonically increasing per workflow)
|
|
48
|
+
- github.event.inputs.* — set for workflow_dispatch when inputs are defined
|
|
49
|
+
fix_code:
|
|
50
|
+
- language: yaml
|
|
51
|
+
label: 'Add || fallback so run-name is readable for all trigger types'
|
|
52
|
+
code: |
|
|
53
|
+
name: Deploy
|
|
54
|
+
# Without || fallback, schedule and workflow_dispatch show "undefined"
|
|
55
|
+
# github.event.head_commit is ONLY available on push events
|
|
56
|
+
run-name: "${{ github.event.head_commit.message || github.event.inputs.reason || 'Scheduled run' }}"
|
|
57
|
+
on:
|
|
58
|
+
push:
|
|
59
|
+
branches: [main]
|
|
60
|
+
schedule:
|
|
61
|
+
- cron: '0 8 * * 1'
|
|
62
|
+
workflow_dispatch:
|
|
63
|
+
inputs:
|
|
64
|
+
reason:
|
|
65
|
+
description: 'Reason for manual trigger'
|
|
66
|
+
required: false
|
|
67
|
+
jobs:
|
|
68
|
+
deploy:
|
|
69
|
+
runs-on: ubuntu-latest
|
|
70
|
+
steps:
|
|
71
|
+
- uses: actions/checkout@v4
|
|
72
|
+
|
|
73
|
+
- language: yaml
|
|
74
|
+
label: 'Use always-populated contexts for a universally safe run-name'
|
|
75
|
+
code: |
|
|
76
|
+
name: Deploy
|
|
77
|
+
# github.actor, github.ref_name, and github.run_number are set for every event
|
|
78
|
+
run-name: '${{ github.actor }} on ${{ github.ref_name }} (#${{ github.run_number }})'
|
|
79
|
+
on:
|
|
80
|
+
push:
|
|
81
|
+
schedule:
|
|
82
|
+
- cron: '0 8 * * 1'
|
|
83
|
+
workflow_dispatch:
|
|
84
|
+
jobs:
|
|
85
|
+
deploy:
|
|
86
|
+
runs-on: ubuntu-latest
|
|
87
|
+
steps:
|
|
88
|
+
- uses: actions/checkout@v4
|
|
89
|
+
prevention:
|
|
90
|
+
- 'Test run-name expressions against every trigger in your on: block — head_commit is only available for push events'
|
|
91
|
+
- 'Always provide a || fallback: github.event.head_commit.message || ''Scheduled run'' handles both push and non-push'
|
|
92
|
+
- 'Prefer github.actor, github.ref_name, and github.run_number — these are populated for every event type'
|
|
93
|
+
- 'Check context availability in the GitHub Docs contexts reference before using event-specific properties in run-name'
|
|
94
|
+
docs:
|
|
95
|
+
- url: 'https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#run-name'
|
|
96
|
+
label: 'GitHub Docs: Workflow syntax — run-name'
|
|
97
|
+
- url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/contexts#github-context'
|
|
98
|
+
label: 'GitHub Docs: github context — event-specific property availability'
|
|
99
|
+
- url: 'https://github.blog/changelog/2022-10-05-github-actions-run-name-and-workflow-run-title/'
|
|
100
|
+
label: 'GitHub Changelog: run-name and workflow run title (October 2022)'
|
package/package.json
CHANGED