@htekdev/actions-debugger 1.0.51 → 1.0.52
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,155 @@
|
|
|
1
|
+
id: caching-artifacts-036
|
|
2
|
+
title: 'actions/cache post step skips save when job is cancelled — cache never populated after cancellation'
|
|
3
|
+
category: caching-artifacts
|
|
4
|
+
severity: silent-failure
|
|
5
|
+
tags:
|
|
6
|
+
- actions-cache
|
|
7
|
+
- job-cancellation
|
|
8
|
+
- post-step
|
|
9
|
+
- cache-save
|
|
10
|
+
- cancel-in-progress
|
|
11
|
+
- concurrency
|
|
12
|
+
- always
|
|
13
|
+
patterns:
|
|
14
|
+
- regex: 'Post\s+Run\s+actions/cache.*skipped|Cache\s+save\s+skipped'
|
|
15
|
+
flags: 'i'
|
|
16
|
+
- regex: 'uses:\s*actions/cache@'
|
|
17
|
+
flags: 'i'
|
|
18
|
+
error_messages:
|
|
19
|
+
- 'Post Run actions/cache@v4 skipped'
|
|
20
|
+
- 'Cache save skipped'
|
|
21
|
+
- '##[warning]Cache save skipped.'
|
|
22
|
+
- 'Warning: Cache save failed.'
|
|
23
|
+
root_cause: |
|
|
24
|
+
The actions/cache action saves the cache in a lifecycle "post" step that runs
|
|
25
|
+
automatically after the main job steps complete. When a job is cancelled — via
|
|
26
|
+
the Actions UI, concurrency cancel-in-progress, or exceeding job timeout-minutes
|
|
27
|
+
— post steps do NOT execute.
|
|
28
|
+
|
|
29
|
+
This creates a cache starvation loop:
|
|
30
|
+
1. Job starts with cache miss — slow dependency installation begins (minutes)
|
|
31
|
+
2. A new push triggers another workflow run while the first is still installing
|
|
32
|
+
3. concurrency: cancel-in-progress terminates the first run mid-install
|
|
33
|
+
4. The first run never reaches its post step — cache is not saved
|
|
34
|
+
5. The second run also sees a cache miss — the same slow install repeats
|
|
35
|
+
6. Repeated cancellations mean the cache is never populated
|
|
36
|
+
|
|
37
|
+
This is invisible in workflow logs: cancelled jobs simply show as cancelled with
|
|
38
|
+
no specific warning about the cache post step being skipped. Teams diagnose it
|
|
39
|
+
as "caching isn't working" without realizing cancellation is the root cause.
|
|
40
|
+
|
|
41
|
+
Affected workflows:
|
|
42
|
+
- Any workflow with concurrency: cancel-in-progress that also uses actions/cache
|
|
43
|
+
- Workflows with aggressive job timeout-minutes that expire during installs
|
|
44
|
+
- Flaky workflows that are frequently manually cancelled and re-run
|
|
45
|
+
- Matrix workflows where one failing matrix branch cancels siblings
|
|
46
|
+
|
|
47
|
+
When a job fails (but is not cancelled), post steps DO run normally — the issue
|
|
48
|
+
is specific to cancellations and hard timeouts.
|
|
49
|
+
fix: |
|
|
50
|
+
Use the split actions/cache/restore + actions/cache/save pattern with
|
|
51
|
+
if: always() on the save step. This gives explicit control over cache saving
|
|
52
|
+
independent of the job lifecycle hooks:
|
|
53
|
+
|
|
54
|
+
- uses: actions/cache/restore@v4
|
|
55
|
+
id: cache-restore
|
|
56
|
+
with:
|
|
57
|
+
key: ...
|
|
58
|
+
path: ...
|
|
59
|
+
|
|
60
|
+
# ... install and build steps ...
|
|
61
|
+
|
|
62
|
+
- uses: actions/cache/save@v4
|
|
63
|
+
if: always()
|
|
64
|
+
with:
|
|
65
|
+
key: ${{ steps.cache-restore.outputs.cache-primary-key }}
|
|
66
|
+
path: ...
|
|
67
|
+
|
|
68
|
+
The split restore/save pattern (available since actions/cache v3.3.0 in 2023)
|
|
69
|
+
runs the save as an explicit step with if: always(), which executes during the
|
|
70
|
+
graceful shutdown window even when the job is being cancelled.
|
|
71
|
+
|
|
72
|
+
Important caveat: if the runner process is killed with SIGKILL (hard preemption,
|
|
73
|
+
host failure), no steps including if: always() will run — this is a
|
|
74
|
+
platform-level constraint outside GitHub Actions' control.
|
|
75
|
+
fix_code:
|
|
76
|
+
- language: yaml
|
|
77
|
+
label: 'Split restore/save pattern with unconditional save to survive cancellation'
|
|
78
|
+
code: |
|
|
79
|
+
jobs:
|
|
80
|
+
build:
|
|
81
|
+
runs-on: ubuntu-latest
|
|
82
|
+
# Even with cancel-in-progress, the explicit save step will run
|
|
83
|
+
concurrency:
|
|
84
|
+
group: ${{ github.workflow }}-${{ github.ref }}
|
|
85
|
+
cancel-in-progress: true
|
|
86
|
+
steps:
|
|
87
|
+
- uses: actions/checkout@v4
|
|
88
|
+
|
|
89
|
+
- name: Restore cached dependencies
|
|
90
|
+
uses: actions/cache/restore@v4
|
|
91
|
+
id: cache-restore
|
|
92
|
+
with:
|
|
93
|
+
path: ~/.npm
|
|
94
|
+
key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
|
|
95
|
+
restore-keys: |
|
|
96
|
+
${{ runner.os }}-npm-
|
|
97
|
+
|
|
98
|
+
- name: Install dependencies
|
|
99
|
+
if: steps.cache-restore.outputs.cache-hit != 'true'
|
|
100
|
+
run: npm ci
|
|
101
|
+
|
|
102
|
+
- name: Run tests
|
|
103
|
+
run: npm test
|
|
104
|
+
|
|
105
|
+
- name: Save cache
|
|
106
|
+
uses: actions/cache/save@v4
|
|
107
|
+
if: always() # Runs during graceful cancellation shutdown window
|
|
108
|
+
with:
|
|
109
|
+
path: ~/.npm
|
|
110
|
+
key: ${{ steps.cache-restore.outputs.cache-primary-key }}
|
|
111
|
+
|
|
112
|
+
- language: yaml
|
|
113
|
+
label: 'Python pip cache with split save pattern'
|
|
114
|
+
code: |
|
|
115
|
+
jobs:
|
|
116
|
+
test:
|
|
117
|
+
runs-on: ubuntu-latest
|
|
118
|
+
steps:
|
|
119
|
+
- uses: actions/checkout@v4
|
|
120
|
+
|
|
121
|
+
- name: Restore pip cache
|
|
122
|
+
uses: actions/cache/restore@v4
|
|
123
|
+
id: pip-cache
|
|
124
|
+
with:
|
|
125
|
+
path: ~/.cache/pip
|
|
126
|
+
key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements*.txt') }}
|
|
127
|
+
restore-keys: |
|
|
128
|
+
${{ runner.os }}-pip-
|
|
129
|
+
|
|
130
|
+
- name: Install Python dependencies
|
|
131
|
+
run: pip install -r requirements.txt
|
|
132
|
+
|
|
133
|
+
- name: Run pytest
|
|
134
|
+
run: pytest
|
|
135
|
+
|
|
136
|
+
- name: Save pip cache
|
|
137
|
+
uses: actions/cache/save@v4
|
|
138
|
+
if: always()
|
|
139
|
+
with:
|
|
140
|
+
path: ~/.cache/pip
|
|
141
|
+
key: ${{ steps.pip-cache.outputs.cache-primary-key }}
|
|
142
|
+
prevention:
|
|
143
|
+
- 'Prefer the split actions/cache/restore + actions/cache/save pattern over the combined actions/cache action for any workflow using concurrency: cancel-in-progress'
|
|
144
|
+
- 'Always add if: always() to explicit cache save steps so they execute regardless of upstream step failure or cancellation signal'
|
|
145
|
+
- 'Monitor workflow logs for "Post Run actions/cache skipped" messages — this is a reliable indicator that cache is never being populated after cancellations'
|
|
146
|
+
- 'Use actions/cache v3.3.0 or later — the split restore/save subactions were introduced in that release'
|
|
147
|
+
docs:
|
|
148
|
+
- url: 'https://github.com/actions/cache/blob/main/save/README.md'
|
|
149
|
+
label: 'actions/cache: Explicit save action documentation'
|
|
150
|
+
- url: 'https://github.com/actions/cache#save-action'
|
|
151
|
+
label: 'actions/cache: Split restore and save usage pattern'
|
|
152
|
+
- url: 'https://github.com/orgs/community/discussions/47469'
|
|
153
|
+
label: 'GitHub Community #47469: Cache not saved when workflow is cancelled'
|
|
154
|
+
- url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-syntax-for-github-actions#jobsjob_idstepsif'
|
|
155
|
+
label: 'GitHub Docs: Using conditions to control job execution'
|
|
@@ -0,0 +1,148 @@
|
|
|
1
|
+
id: permissions-auth-038
|
|
2
|
+
title: 'secrets: inherit does not propagate environment-scoped secrets to reusable workflows'
|
|
3
|
+
category: permissions-auth
|
|
4
|
+
severity: silent-failure
|
|
5
|
+
tags:
|
|
6
|
+
- secrets-inherit
|
|
7
|
+
- reusable-workflows
|
|
8
|
+
- environment-secrets
|
|
9
|
+
- workflow-call
|
|
10
|
+
- empty-secret
|
|
11
|
+
- deployment-environment
|
|
12
|
+
patterns:
|
|
13
|
+
- regex: 'secrets:\s*inherit'
|
|
14
|
+
flags: 'i'
|
|
15
|
+
- regex: 'uses:\s*[./\w@-]+\.ya?ml\b'
|
|
16
|
+
flags: 'i'
|
|
17
|
+
error_messages:
|
|
18
|
+
- 'Error: Input required and not supplied'
|
|
19
|
+
- 'Secret value is empty in reusable workflow'
|
|
20
|
+
- '##[error]The secret variable name is invalid'
|
|
21
|
+
root_cause: |
|
|
22
|
+
When a caller workflow uses secrets: inherit to call a reusable workflow
|
|
23
|
+
(on.workflow_call), GitHub passes repository-level and organization-level
|
|
24
|
+
secrets to the called workflow. However, environment-scoped secrets are NOT
|
|
25
|
+
inherited — they arrive as empty strings with no error or warning.
|
|
26
|
+
|
|
27
|
+
Environment secrets are tied to a named deployment environment (e.g.,
|
|
28
|
+
"production", "staging") and are only accessible to jobs that declare
|
|
29
|
+
environment: <name> in their configuration. The secrets: inherit mechanism
|
|
30
|
+
operates at the repository/org secret scope level. It cannot bridge environment
|
|
31
|
+
context to a called workflow's jobs because those jobs run in a separate
|
|
32
|
+
workflow execution context and do not inherit the caller job's environment
|
|
33
|
+
declaration.
|
|
34
|
+
|
|
35
|
+
Failure scenario:
|
|
36
|
+
1. Caller job declares environment: production (activates env secrets in the caller)
|
|
37
|
+
2. Caller job uses secrets: inherit to call ./reusable.yml
|
|
38
|
+
3. Reusable workflow job reads secrets.PROD_DB_PASSWORD (an environment secret)
|
|
39
|
+
4. Reusable workflow job sees PROD_DB_PASSWORD as empty string
|
|
40
|
+
5. No error is thrown — the secret silently resolves to ""
|
|
41
|
+
|
|
42
|
+
This is documented as a GitHub platform limitation in the reusable workflows
|
|
43
|
+
documentation. GitHub Community discussion #26671 has many reports of this
|
|
44
|
+
surprising behavior.
|
|
45
|
+
|
|
46
|
+
Distinction from permissions-auth-037 (environment-secrets-job-scope):
|
|
47
|
+
- permissions-auth-037 covers jobs in the SAME workflow that lack environment:
|
|
48
|
+
declarations failing to access environment secrets.
|
|
49
|
+
- This entry covers the cross-workflow boundary where secrets: inherit does not
|
|
50
|
+
transfer environment secrets from caller to called workflow at all.
|
|
51
|
+
fix: |
|
|
52
|
+
Explicitly declare and map environment secrets at the workflow_call boundary.
|
|
53
|
+
In the reusable workflow, declare each secret in the on.workflow_call.secrets
|
|
54
|
+
block. At the call site, explicitly pass each environment secret using the
|
|
55
|
+
secrets: mapping block (not secrets: inherit):
|
|
56
|
+
|
|
57
|
+
In the reusable workflow (workflow_call trigger):
|
|
58
|
+
on:
|
|
59
|
+
workflow_call:
|
|
60
|
+
secrets:
|
|
61
|
+
db_password:
|
|
62
|
+
required: true
|
|
63
|
+
api_key:
|
|
64
|
+
required: false
|
|
65
|
+
|
|
66
|
+
In the calling workflow:
|
|
67
|
+
jobs:
|
|
68
|
+
deploy:
|
|
69
|
+
environment: production
|
|
70
|
+
uses: ./.github/workflows/deploy.yml
|
|
71
|
+
secrets:
|
|
72
|
+
db_password: ${{ secrets.PROD_DB_PASSWORD }}
|
|
73
|
+
api_key: ${{ secrets.PROD_API_KEY }}
|
|
74
|
+
|
|
75
|
+
Alternatively, if the reusable workflow is in the same repository and the
|
|
76
|
+
environment name is fixed, you can declare environment: production on the job
|
|
77
|
+
inside the reusable workflow directly. This makes environment secrets accessible
|
|
78
|
+
in the called workflow at the cost of coupling it to a specific environment name.
|
|
79
|
+
|
|
80
|
+
Note: secrets: inherit and explicit secrets: mapping cannot be combined on the
|
|
81
|
+
same uses: step. Choose one approach: either inherit all repo/org secrets, or
|
|
82
|
+
map explicitly (which also allows passing environment secrets).
|
|
83
|
+
fix_code:
|
|
84
|
+
- language: yaml
|
|
85
|
+
label: 'Reusable workflow — declare required secrets in workflow_call trigger'
|
|
86
|
+
code: |
|
|
87
|
+
# .github/workflows/deploy-reusable.yml
|
|
88
|
+
on:
|
|
89
|
+
workflow_call:
|
|
90
|
+
secrets:
|
|
91
|
+
db_password:
|
|
92
|
+
required: true
|
|
93
|
+
api_key:
|
|
94
|
+
required: true
|
|
95
|
+
|
|
96
|
+
jobs:
|
|
97
|
+
deploy:
|
|
98
|
+
runs-on: ubuntu-latest
|
|
99
|
+
steps:
|
|
100
|
+
- name: Deploy application
|
|
101
|
+
env:
|
|
102
|
+
DB_PASSWORD: ${{ secrets.db_password }}
|
|
103
|
+
API_KEY: ${{ secrets.api_key }}
|
|
104
|
+
run: ./scripts/deploy.sh
|
|
105
|
+
|
|
106
|
+
- language: yaml
|
|
107
|
+
label: 'Caller workflow — explicitly map environment secrets (not secrets: inherit)'
|
|
108
|
+
code: |
|
|
109
|
+
# .github/workflows/deploy-caller.yml
|
|
110
|
+
jobs:
|
|
111
|
+
call-deploy:
|
|
112
|
+
environment: production # Activates environment secrets in this calling job
|
|
113
|
+
uses: ./.github/workflows/deploy-reusable.yml
|
|
114
|
+
# WRONG: secrets: inherit -- passes repo/org secrets but NOT environment secrets
|
|
115
|
+
secrets:
|
|
116
|
+
db_password: ${{ secrets.PROD_DB_PASSWORD }} # Environment secret — must be explicit
|
|
117
|
+
api_key: ${{ secrets.PROD_API_KEY }} # Environment secret — must be explicit
|
|
118
|
+
|
|
119
|
+
- language: yaml
|
|
120
|
+
label: 'Alternative — declare environment inside the reusable workflow job'
|
|
121
|
+
code: |
|
|
122
|
+
# .github/workflows/deploy-reusable.yml (alternative approach)
|
|
123
|
+
on:
|
|
124
|
+
workflow_call: {}
|
|
125
|
+
|
|
126
|
+
jobs:
|
|
127
|
+
deploy:
|
|
128
|
+
runs-on: ubuntu-latest
|
|
129
|
+
environment: production # Directly activates environment secrets here
|
|
130
|
+
steps: # Couples reusable workflow to environment name
|
|
131
|
+
- name: Deploy application
|
|
132
|
+
env:
|
|
133
|
+
DB_PASSWORD: ${{ secrets.PROD_DB_PASSWORD }}
|
|
134
|
+
run: ./scripts/deploy.sh
|
|
135
|
+
prevention:
|
|
136
|
+
- 'Never rely on secrets: inherit to pass environment-scoped secrets — always map them explicitly in the secrets: block of the workflow_call invocation'
|
|
137
|
+
- 'In reusable workflows, declare all required secrets in on.workflow_call.secrets with required: true so missing secrets fail loudly rather than silently resolving to empty strings'
|
|
138
|
+
- 'Document which secrets in your reusable workflow are environment-scoped vs repository-scoped so callers know the correct passing strategy'
|
|
139
|
+
- 'Test reusable workflows end-to-end from a caller workflow before deploying to production — secrets: inherit working in testing does not guarantee environment secrets work correctly'
|
|
140
|
+
docs:
|
|
141
|
+
- url: 'https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-secrets-to-called-workflows'
|
|
142
|
+
label: 'GitHub Docs: Passing secrets to called workflows'
|
|
143
|
+
- url: 'https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-an-environment'
|
|
144
|
+
label: 'GitHub Docs: Creating secrets for an environment'
|
|
145
|
+
- url: 'https://github.com/orgs/community/discussions/26671'
|
|
146
|
+
label: 'GitHub Community #26671: secrets: inherit not passing environment secrets'
|
|
147
|
+
- url: 'https://docs.github.com/en/actions/sharing-automations/reusing-workflows#limitations'
|
|
148
|
+
label: 'GitHub Docs: Reusable workflows — limitations'
|
|
@@ -0,0 +1,113 @@
|
|
|
1
|
+
id: runner-environment-110
|
|
2
|
+
title: 'actions/checkout default fetch-depth:1 shallow clone breaks git describe and changelog generation'
|
|
3
|
+
category: runner-environment
|
|
4
|
+
severity: error
|
|
5
|
+
tags:
|
|
6
|
+
- checkout
|
|
7
|
+
- fetch-depth
|
|
8
|
+
- shallow-clone
|
|
9
|
+
- git-describe
|
|
10
|
+
- versioning
|
|
11
|
+
- changelog
|
|
12
|
+
- tags
|
|
13
|
+
- release
|
|
14
|
+
patterns:
|
|
15
|
+
- regex: 'fatal:\s*No names found.*cannot describe|No tag can describe'
|
|
16
|
+
flags: 'i'
|
|
17
|
+
- regex: 'fetch-depth:\s*[01]\b'
|
|
18
|
+
flags: 'i'
|
|
19
|
+
error_messages:
|
|
20
|
+
- 'fatal: No names found, cannot describe anything.'
|
|
21
|
+
- 'fatal: No tags can describe ''HEAD''.'
|
|
22
|
+
- 'error: No annotated tags can describe'
|
|
23
|
+
- '##[error]fatal: no tag exactly matches'
|
|
24
|
+
root_cause: |
|
|
25
|
+
actions/checkout defaults to fetch-depth: 1 — a shallow clone that downloads
|
|
26
|
+
only the single most recent commit. This optimizes CI download speed but breaks
|
|
27
|
+
any operation that requires commit history or reachable tag ancestry:
|
|
28
|
+
|
|
29
|
+
- git describe --tags: requires a tag somewhere in the commit ancestry chain.
|
|
30
|
+
With depth 1, no ancestor commits exist, so no tags are reachable unless the
|
|
31
|
+
HEAD commit IS exactly the tagged commit. Returns "fatal: No names found,
|
|
32
|
+
cannot describe anything."
|
|
33
|
+
|
|
34
|
+
- Changelog generators (conventional-changelog, release-please, git-cliff,
|
|
35
|
+
semantic-release): need commit history to determine what changed since the
|
|
36
|
+
last release. With depth 1, they see zero commits and produce empty changelogs.
|
|
37
|
+
|
|
38
|
+
- Semantic versioning tools that count commits since last tag always return 0
|
|
39
|
+
because no prior commits (and thus no tags) are in the shallow history.
|
|
40
|
+
|
|
41
|
+
- Branch comparison and merge-base operations: git merge-base fails or produces
|
|
42
|
+
incorrect results with no shared history available.
|
|
43
|
+
|
|
44
|
+
A common workaround attempt — using fetch-tags: true with fetch-depth: 1 —
|
|
45
|
+
fetches tag objects but NOT the commits they point to in history, so
|
|
46
|
+
git describe still fails. The tags exist as objects but are not reachable from
|
|
47
|
+
HEAD via the commit graph.
|
|
48
|
+
|
|
49
|
+
This is one of the most-discussed GitHub Community topics: the checkout step
|
|
50
|
+
looks correct, CI succeeds, but release version numbers or changelogs are
|
|
51
|
+
unexpectedly empty or wrong, often discovered only after a real release attempt.
|
|
52
|
+
fix: |
|
|
53
|
+
Set fetch-depth: 0 to fetch complete commit history including all tags:
|
|
54
|
+
|
|
55
|
+
- uses: actions/checkout@v4
|
|
56
|
+
with:
|
|
57
|
+
fetch-depth: 0
|
|
58
|
+
|
|
59
|
+
For large repositories where full history is prohibitively slow, use targeted
|
|
60
|
+
approaches:
|
|
61
|
+
- fetch-depth: 50 covers the last 50 commits — sufficient for active repos
|
|
62
|
+
that tag frequently, but risky for repos with infrequent tagging.
|
|
63
|
+
- fetch-depth: 0 combined with --filter=blob:none (partial clone) gets history
|
|
64
|
+
metadata without full file blobs — not directly configurable in the action but
|
|
65
|
+
achievable via fetch options in post-checkout scripts for advanced cases.
|
|
66
|
+
|
|
67
|
+
For changelog and release tools (release-please, git-cliff, semantic-release,
|
|
68
|
+
conventional-changelog), always use fetch-depth: 0. These tools explicitly
|
|
69
|
+
require full history and their documentation states this requirement.
|
|
70
|
+
fix_code:
|
|
71
|
+
- language: yaml
|
|
72
|
+
label: 'Full history checkout for git describe and changelog generation tools'
|
|
73
|
+
code: |
|
|
74
|
+
jobs:
|
|
75
|
+
release:
|
|
76
|
+
runs-on: ubuntu-latest
|
|
77
|
+
steps:
|
|
78
|
+
- uses: actions/checkout@v4
|
|
79
|
+
with:
|
|
80
|
+
fetch-depth: 0 # Full history required for version detection and changelogs
|
|
81
|
+
# Default fetch-depth: 1 (shallow) causes "No names found, cannot describe"
|
|
82
|
+
|
|
83
|
+
- name: Generate changelog
|
|
84
|
+
uses: orhun/git-cliff-action@v3
|
|
85
|
+
with:
|
|
86
|
+
config: cliff.toml
|
|
87
|
+
|
|
88
|
+
- language: yaml
|
|
89
|
+
label: 'Partial depth with fetch-tags for large repos — use with caution'
|
|
90
|
+
code: |
|
|
91
|
+
jobs:
|
|
92
|
+
version:
|
|
93
|
+
runs-on: ubuntu-latest
|
|
94
|
+
steps:
|
|
95
|
+
- uses: actions/checkout@v4
|
|
96
|
+
with:
|
|
97
|
+
fetch-depth: 100 # Last 100 commits — sufficient for frequently-tagged repos
|
|
98
|
+
fetch-tags: true # Fetch tag objects so they appear in tag list
|
|
99
|
+
# WARNING: fetch-tags: true with a shallow clone fetches tag OBJECTS
|
|
100
|
+
# but NOT their commit ancestors — git describe may still fail if
|
|
101
|
+
# the tag is older than fetch-depth commits. Use fetch-depth: 0 to be safe.
|
|
102
|
+
prevention:
|
|
103
|
+
- 'Set fetch-depth: 0 in any workflow that uses git describe, generates a changelog, or computes a semantic version from commit history'
|
|
104
|
+
- 'Document in your workflow why fetch-depth: 0 is required so future maintainers do not revert it to the shallow default'
|
|
105
|
+
- 'Do not assume fetch-tags: true solves shallow clone limitations for git describe — the tag objects must be reachable in the commit graph'
|
|
106
|
+
- 'Keep the default fetch-depth: 1 only for workflows that never need commit history — pure build and test jobs with no versioning or history analysis'
|
|
107
|
+
docs:
|
|
108
|
+
- url: 'https://github.com/actions/checkout#usage'
|
|
109
|
+
label: 'actions/checkout: fetch-depth parameter documentation'
|
|
110
|
+
- url: 'https://github.com/orgs/community/discussions/25702'
|
|
111
|
+
label: 'GitHub Community: git describe fails with actions/checkout shallow clone'
|
|
112
|
+
- url: 'https://github.com/actions/checkout/issues/701'
|
|
113
|
+
label: 'actions/checkout #701: fetch-tags does not help with git describe on shallow clone'
|
|
@@ -0,0 +1,111 @@
|
|
|
1
|
+
id: silent-failures-053
|
|
2
|
+
title: 'workflow_dispatch boolean inputs arrive as strings — if: inputs.flag is always truthy'
|
|
3
|
+
category: silent-failures
|
|
4
|
+
severity: silent-failure
|
|
5
|
+
tags:
|
|
6
|
+
- workflow-dispatch
|
|
7
|
+
- boolean-inputs
|
|
8
|
+
- type-coercion
|
|
9
|
+
- inputs-context
|
|
10
|
+
- string-comparison
|
|
11
|
+
- if-condition
|
|
12
|
+
patterns:
|
|
13
|
+
- regex: 'inputs\.\w+\s*==\s*true\b'
|
|
14
|
+
flags: 'i'
|
|
15
|
+
- regex: 'if:\s*inputs\.\w+'
|
|
16
|
+
flags: 'i'
|
|
17
|
+
error_messages:
|
|
18
|
+
- 'Step always runs even when boolean input is set to false'
|
|
19
|
+
- 'Boolean workflow_dispatch input behaves as truthy regardless of value'
|
|
20
|
+
root_cause: |
|
|
21
|
+
GitHub Actions workflow_dispatch inputs defined with type: boolean are passed
|
|
22
|
+
to the workflow as strings ("true" or "false"), not as JavaScript/YAML booleans.
|
|
23
|
+
|
|
24
|
+
This means three common patterns silently misbehave:
|
|
25
|
+
- if: inputs.dry_run evaluates to always truthy (non-empty string)
|
|
26
|
+
- if: inputs.dry_run == true always false (string "true" != boolean true)
|
|
27
|
+
- if: inputs.dry_run == false always false (string "false" != boolean false)
|
|
28
|
+
|
|
29
|
+
The GitHub Actions expression evaluator converts the inputs context to strings
|
|
30
|
+
at the boundary between the event payload and the workflow context. Even though
|
|
31
|
+
the UI renders a checkbox, the underlying value is the literal string "true" or
|
|
32
|
+
"false". This behavior is consistent across workflow_dispatch and workflow_call
|
|
33
|
+
inputs of type boolean.
|
|
34
|
+
|
|
35
|
+
GitHub Community discussion #51504 documents this as expected behavior, but
|
|
36
|
+
thousands of developers are surprised by the mismatch between the checkbox UI
|
|
37
|
+
and the string runtime value.
|
|
38
|
+
|
|
39
|
+
Affected patterns:
|
|
40
|
+
- if: inputs.dry_run (truthy check — always true for any non-empty string value)
|
|
41
|
+
- if: inputs.flag == true (boolean comparison — always false for string "true")
|
|
42
|
+
- Ternary: ${{ inputs.flag && 'yes' || 'no' }} returns "yes" even when flag is "false"
|
|
43
|
+
fix: |
|
|
44
|
+
Always compare workflow_dispatch boolean inputs to the string literal 'true'
|
|
45
|
+
or 'false':
|
|
46
|
+
|
|
47
|
+
- if: inputs.dry_run == 'true' correct
|
|
48
|
+
- if: inputs.dry_run != 'true' correct negation (catches "false" and "")
|
|
49
|
+
- if: inputs.dry_run == true WRONG — string never equals boolean
|
|
50
|
+
- if: inputs.dry_run WRONG — always truthy for non-empty string
|
|
51
|
+
|
|
52
|
+
For workflow_call with boolean inputs, the same string coercion applies when
|
|
53
|
+
the calling workflow passes the value via the inputs: block.
|
|
54
|
+
|
|
55
|
+
The fromJSON() function converts the string to a real boolean if needed for
|
|
56
|
+
complex conditions: fromJSON(inputs.dry_run) returns actual true/false booleans.
|
|
57
|
+
fix_code:
|
|
58
|
+
- language: yaml
|
|
59
|
+
label: 'Correct boolean input comparison using string equality'
|
|
60
|
+
code: |
|
|
61
|
+
on:
|
|
62
|
+
workflow_dispatch:
|
|
63
|
+
inputs:
|
|
64
|
+
dry_run:
|
|
65
|
+
description: 'Run without making changes'
|
|
66
|
+
type: boolean
|
|
67
|
+
default: false
|
|
68
|
+
|
|
69
|
+
jobs:
|
|
70
|
+
deploy:
|
|
71
|
+
runs-on: ubuntu-latest
|
|
72
|
+
steps:
|
|
73
|
+
- name: Deploy (skip if dry run)
|
|
74
|
+
# WRONG: if: inputs.dry_run -- always truthy (non-empty string)
|
|
75
|
+
# WRONG: if: inputs.dry_run == true -- string never equals boolean
|
|
76
|
+
if: inputs.dry_run != 'true'
|
|
77
|
+
run: echo "Deploying..."
|
|
78
|
+
|
|
79
|
+
- name: Dry run notice
|
|
80
|
+
if: inputs.dry_run == 'true'
|
|
81
|
+
run: echo "Dry run mode — no changes made"
|
|
82
|
+
|
|
83
|
+
- language: yaml
|
|
84
|
+
label: 'Use fromJSON() to convert to real boolean for complex conditions'
|
|
85
|
+
code: |
|
|
86
|
+
jobs:
|
|
87
|
+
build:
|
|
88
|
+
runs-on: ubuntu-latest
|
|
89
|
+
steps:
|
|
90
|
+
- name: Conditional step using fromJSON conversion
|
|
91
|
+
if: fromJSON(inputs.dry_run) == false
|
|
92
|
+
run: echo "Not a dry run — proceeding"
|
|
93
|
+
|
|
94
|
+
- name: Set environment variable from boolean input
|
|
95
|
+
env:
|
|
96
|
+
# fromJSON converts "true"/"false" string to actual boolean
|
|
97
|
+
DRY_RUN: ${{ fromJSON(inputs.dry_run) }}
|
|
98
|
+
run: |
|
|
99
|
+
echo "Dry run mode: $DRY_RUN"
|
|
100
|
+
prevention:
|
|
101
|
+
- 'Always compare workflow_dispatch boolean inputs to the string literal ''true'' or ''false'', not to boolean true/false'
|
|
102
|
+
- 'Never use ''if: inputs.flag'' alone as a boolean check — the non-empty string "false" is truthy in GitHub Actions expressions'
|
|
103
|
+
- 'Use fromJSON(inputs.flag) when you need a real boolean value in expressions or env: context'
|
|
104
|
+
- 'Add a comment in your workflow noting that boolean dispatch inputs are strings at runtime to warn future maintainers'
|
|
105
|
+
docs:
|
|
106
|
+
- url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-syntax-for-github-actions#onworkflow_dispatchinputs'
|
|
107
|
+
label: 'GitHub Docs: workflow_dispatch inputs syntax'
|
|
108
|
+
- url: 'https://github.com/orgs/community/discussions/51504'
|
|
109
|
+
label: 'GitHub Community #51504: Boolean inputs in workflow_dispatch are strings'
|
|
110
|
+
- url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions#fromjson'
|
|
111
|
+
label: 'GitHub Docs: fromJSON expression function'
|
package/package.json
CHANGED