@htekdev/actions-debugger 1.0.68 → 1.0.69
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.
- package/errors/known-unsolved/composite-action-no-pre-post-lifecycle-hooks.yml +94 -0
- package/errors/runner-environment/docker-build-push-provenance-default-manifest-index.yml +81 -0
- package/errors/runner-environment/setup-node-yarn-packagemanager-corepack-conflict.yml +71 -0
- package/errors/triggers/schedule-workflow-disabled-on-fork.yml +69 -0
- package/package.json +1 -1
|
@@ -0,0 +1,94 @@
|
|
|
1
|
+
id: known-unsolved-043
|
|
2
|
+
title: 'Composite actions do not support pre: and post: lifecycle hooks — no guaranteed setup or cleanup code'
|
|
3
|
+
category: known-unsolved
|
|
4
|
+
severity: limitation
|
|
5
|
+
tags:
|
|
6
|
+
- composite-action
|
|
7
|
+
- pre-step
|
|
8
|
+
- post-step
|
|
9
|
+
- cleanup
|
|
10
|
+
- lifecycle
|
|
11
|
+
patterns:
|
|
12
|
+
- regex: 'Unexpected value ''pre'''
|
|
13
|
+
flags: 'i'
|
|
14
|
+
- regex: 'Unexpected value ''post'''
|
|
15
|
+
flags: 'i'
|
|
16
|
+
error_messages:
|
|
17
|
+
- "Unexpected value 'pre'"
|
|
18
|
+
- "Unexpected value 'post'"
|
|
19
|
+
- 'pre: and post: are only supported in JavaScript and Docker container actions'
|
|
20
|
+
root_cause: |
|
|
21
|
+
GitHub Actions supports pre: and post: lifecycle hooks in JavaScript actions (using: node20/node24)
|
|
22
|
+
and Docker container actions (using: docker). These hooks run before and after the main action
|
|
23
|
+
step respectively, and the post: hook runs even when the workflow is cancelled or fails —
|
|
24
|
+
making them ideal for guaranteed resource cleanup.
|
|
25
|
+
|
|
26
|
+
Composite actions (using: composite) do NOT support pre: or post: hooks. Attempting to add
|
|
27
|
+
pre: or post: to an action.yml with using: composite causes a validation error. This means
|
|
28
|
+
shell-based or Python-based composite actions cannot register guaranteed cleanup code that
|
|
29
|
+
runs after the job, regardless of success, failure, or cancellation.
|
|
30
|
+
|
|
31
|
+
Common affected patterns:
|
|
32
|
+
- Database seeding in setup steps that must be torn down in post:
|
|
33
|
+
- Port forwarding or tunnel setup that must be closed after the job
|
|
34
|
+
- Temporary credential setup that must be revoked after the workflow
|
|
35
|
+
- Cloud resource creation that must be deleted to avoid cost leaks
|
|
36
|
+
fix: |
|
|
37
|
+
There is no direct fix — this is a known GitHub Actions platform limitation. Common workarounds:
|
|
38
|
+
|
|
39
|
+
Option A: Add explicit cleanup steps in calling workflows using if: always().
|
|
40
|
+
Option B: Wrap the composite logic in a thin JavaScript action that shells out to scripts,
|
|
41
|
+
enabling pre:/post: hook support.
|
|
42
|
+
Option C: Use a separate cleanup job with needs: [main-job] and if: always() for teardown.
|
|
43
|
+
Note: Option C adds latency and does not run on runner process kill.
|
|
44
|
+
fix_code:
|
|
45
|
+
- language: yaml
|
|
46
|
+
label: 'Workaround: use if: always() cleanup step in the calling workflow'
|
|
47
|
+
code: |
|
|
48
|
+
jobs:
|
|
49
|
+
build:
|
|
50
|
+
runs-on: ubuntu-latest
|
|
51
|
+
steps:
|
|
52
|
+
- name: Setup composite action
|
|
53
|
+
uses: ./.github/actions/my-composite-action
|
|
54
|
+
|
|
55
|
+
- name: Run build
|
|
56
|
+
run: make build
|
|
57
|
+
|
|
58
|
+
# Cleanup runs even if previous steps fail or are cancelled
|
|
59
|
+
- name: Cleanup resources
|
|
60
|
+
if: always()
|
|
61
|
+
run: |
|
|
62
|
+
echo "Cleaning up resources created by composite action..."
|
|
63
|
+
# teardown commands here
|
|
64
|
+
|
|
65
|
+
- language: yaml
|
|
66
|
+
label: 'Workaround: separate cleanup job guaranteed to run after main job'
|
|
67
|
+
code: |
|
|
68
|
+
jobs:
|
|
69
|
+
build:
|
|
70
|
+
runs-on: ubuntu-latest
|
|
71
|
+
steps:
|
|
72
|
+
- uses: ./.github/actions/my-composite-action
|
|
73
|
+
- run: make build
|
|
74
|
+
|
|
75
|
+
cleanup:
|
|
76
|
+
runs-on: ubuntu-latest
|
|
77
|
+
needs: [build]
|
|
78
|
+
# Runs even when the build job fails or is cancelled
|
|
79
|
+
if: always()
|
|
80
|
+
steps:
|
|
81
|
+
- name: Teardown
|
|
82
|
+
run: |
|
|
83
|
+
echo "Running post-job cleanup..."
|
|
84
|
+
prevention:
|
|
85
|
+
- "Design composite actions to be stateless and idempotent when possible — avoid side effects that require guaranteed cleanup"
|
|
86
|
+
- "Document in the composite action README that callers must add if: always() cleanup steps"
|
|
87
|
+
- "For actions that require guaranteed pre:/post: lifecycle hooks, consider wrapping in a JavaScript action"
|
|
88
|
+
docs:
|
|
89
|
+
- url: 'https://github.com/actions/runner/issues/1478'
|
|
90
|
+
label: 'actions/runner#1478 — Support pre and post steps in Composite Actions (393 reactions)'
|
|
91
|
+
- url: 'https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#runs-for-composite-actions'
|
|
92
|
+
label: 'Metadata syntax for composite actions — GitHub Docs'
|
|
93
|
+
- url: 'https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#runspre'
|
|
94
|
+
label: 'pre: lifecycle hook — JavaScript and Docker actions only'
|
|
@@ -0,0 +1,81 @@
|
|
|
1
|
+
id: runner-environment-130
|
|
2
|
+
title: 'docker/build-push-action default provenance: true pushes OCI image index for single-platform builds — breaks registries that do not support image indexes'
|
|
3
|
+
category: runner-environment
|
|
4
|
+
severity: silent-failure
|
|
5
|
+
tags:
|
|
6
|
+
- docker
|
|
7
|
+
- build-push-action
|
|
8
|
+
- provenance
|
|
9
|
+
- oci
|
|
10
|
+
- manifest-index
|
|
11
|
+
patterns:
|
|
12
|
+
- regex: 'manifest unknown'
|
|
13
|
+
flags: 'i'
|
|
14
|
+
- regex: 'unexpected status: \d{3}'
|
|
15
|
+
flags: 'i'
|
|
16
|
+
error_messages:
|
|
17
|
+
- 'manifest unknown'
|
|
18
|
+
- 'unexpected status: 400'
|
|
19
|
+
- 'unexpected status: 403'
|
|
20
|
+
root_cause: |
|
|
21
|
+
Starting with docker/build-push-action v4, the provenance input defaults to mode=min,
|
|
22
|
+
which attaches an SLSA provenance attestation to every pushed image. This causes the action
|
|
23
|
+
to push an OCI image index (manifest list) to the registry instead of a plain image manifest,
|
|
24
|
+
even for single-platform builds.
|
|
25
|
+
|
|
26
|
+
Registries and tools that do not support OCI image indexes may return "manifest unknown"
|
|
27
|
+
errors, return 400/403 HTTP responses, or silently resolve to an unexpected image variant.
|
|
28
|
+
Some container registries (such as older versions of GCR) display the provenance attestation
|
|
29
|
+
as a separate image entry with a creation timestamp of 0 epoch (Unix epoch), causing
|
|
30
|
+
confusion in image management dashboards.
|
|
31
|
+
|
|
32
|
+
The behavior is silent in successful-looking cases: the push completes without error, but
|
|
33
|
+
downstream 'docker pull' or 'FROM image:tag' in a Dockerfile may resolve the image index
|
|
34
|
+
instead of a plain image manifest, causing unexpected platform or size differences.
|
|
35
|
+
fix: |
|
|
36
|
+
Set provenance: false in docker/build-push-action to restore plain image manifest behavior
|
|
37
|
+
for single-platform builds. If SLSA provenance is required, use actions/attest-build-provenance
|
|
38
|
+
as a separate step after the push.
|
|
39
|
+
fix_code:
|
|
40
|
+
- language: yaml
|
|
41
|
+
label: 'Disable provenance to push plain image manifest for single-platform builds'
|
|
42
|
+
code: |
|
|
43
|
+
- name: Build and push
|
|
44
|
+
uses: docker/build-push-action@v6
|
|
45
|
+
with:
|
|
46
|
+
context: .
|
|
47
|
+
push: true
|
|
48
|
+
tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest
|
|
49
|
+
# Disable default provenance attestation to push a plain image manifest.
|
|
50
|
+
# Required for registries that do not support OCI image indexes.
|
|
51
|
+
provenance: false
|
|
52
|
+
|
|
53
|
+
- language: yaml
|
|
54
|
+
label: 'Add SLSA provenance separately using actions/attest-build-provenance'
|
|
55
|
+
code: |
|
|
56
|
+
- name: Build and push
|
|
57
|
+
id: push
|
|
58
|
+
uses: docker/build-push-action@v6
|
|
59
|
+
with:
|
|
60
|
+
context: .
|
|
61
|
+
push: true
|
|
62
|
+
tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest
|
|
63
|
+
provenance: false
|
|
64
|
+
|
|
65
|
+
- name: Attest build provenance
|
|
66
|
+
uses: actions/attest-build-provenance@v2
|
|
67
|
+
with:
|
|
68
|
+
subject-name: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
|
|
69
|
+
subject-digest: ${{ steps.push.outputs.digest }}
|
|
70
|
+
push-to-registry: true
|
|
71
|
+
prevention:
|
|
72
|
+
- "Set 'provenance: false' in docker/build-push-action unless your target registry explicitly supports OCI image indexes"
|
|
73
|
+
- "Test image pulling from the registry after pushing to confirm the correct manifest type was stored"
|
|
74
|
+
- "Use 'docker manifest inspect' to verify the pushed image is a plain manifest and not a manifest index when provenance is enabled"
|
|
75
|
+
docs:
|
|
76
|
+
- url: 'https://github.com/docker/build-push-action/issues/755'
|
|
77
|
+
label: 'docker/build-push-action#755 — Action started to push manifest indexes instead of images for a single platform'
|
|
78
|
+
- url: 'https://docs.docker.com/build/ci/github-actions/attestations/'
|
|
79
|
+
label: 'Docker build attestations with GitHub Actions'
|
|
80
|
+
- url: 'https://docs.docker.com/reference/cli/docker/buildx/build/#provenance'
|
|
81
|
+
label: 'docker buildx build --provenance flag documentation'
|
|
@@ -0,0 +1,71 @@
|
|
|
1
|
+
id: runner-environment-129
|
|
2
|
+
title: 'setup-node cache: yarn fails when packageManager specifies Yarn 4 in package.json — Corepack version mismatch'
|
|
3
|
+
category: runner-environment
|
|
4
|
+
severity: error
|
|
5
|
+
tags:
|
|
6
|
+
- setup-node
|
|
7
|
+
- yarn
|
|
8
|
+
- corepack
|
|
9
|
+
- packageManager
|
|
10
|
+
- package-json
|
|
11
|
+
patterns:
|
|
12
|
+
- regex: 'Presence of the "packageManager" field indicates that the project is meant to be used with Corepack'
|
|
13
|
+
flags: 'i'
|
|
14
|
+
- regex: 'the current global version of Yarn is \d+\.\d+'
|
|
15
|
+
flags: 'i'
|
|
16
|
+
error_messages:
|
|
17
|
+
- 'This project''s package.json defines "packageManager": "yarn@4.x.x". However the current global version of Yarn is 1.22.22.'
|
|
18
|
+
- 'Presence of the "packageManager" field indicates that the project is meant to be used with Corepack'
|
|
19
|
+
root_cause: |
|
|
20
|
+
When package.json contains a "packageManager" field specifying Yarn 4 (e.g., "yarn@4.1.1"),
|
|
21
|
+
Yarn's integrity check detects the field and requires the project to be managed via Corepack.
|
|
22
|
+
The system Yarn installed on GitHub-hosted runners is Yarn Classic (1.x), which responds to
|
|
23
|
+
the "packageManager" constraint by throwing an error if Corepack is not enabled.
|
|
24
|
+
|
|
25
|
+
When actions/setup-node is configured with cache: 'yarn', it detects the "packageManager"
|
|
26
|
+
field, attempts to use the specified Yarn version via Corepack, but Corepack is not enabled
|
|
27
|
+
by default on GitHub-hosted runners. The resulting error prevents setup-node from completing
|
|
28
|
+
and fails the job before any build steps run.
|
|
29
|
+
|
|
30
|
+
This affects workflows being upgraded from Yarn Classic to Yarn 4 (Berry) via the
|
|
31
|
+
"packageManager" field in package.json, or projects that adopted the "packageManager"
|
|
32
|
+
field for strict version pinning.
|
|
33
|
+
fix: |
|
|
34
|
+
Enable Corepack before running setup-node. Two options depending on your setup-node version:
|
|
35
|
+
|
|
36
|
+
Option A: Add a 'corepack enable' run step before setup-node (works with all versions).
|
|
37
|
+
Option B: Use 'enable-node-corepack: true' input (requires setup-node v4.2+).
|
|
38
|
+
Option C: Remove 'packageManager' from package.json and manage Yarn version via .yarnrc.yml only.
|
|
39
|
+
fix_code:
|
|
40
|
+
- language: yaml
|
|
41
|
+
label: 'Enable Corepack before setup-node (Yarn 4 / Berry projects)'
|
|
42
|
+
code: |
|
|
43
|
+
- name: Enable Corepack
|
|
44
|
+
run: corepack enable
|
|
45
|
+
|
|
46
|
+
- name: Set up Node.js with Yarn cache
|
|
47
|
+
uses: actions/setup-node@v4
|
|
48
|
+
with:
|
|
49
|
+
node-version: '20'
|
|
50
|
+
cache: 'yarn'
|
|
51
|
+
|
|
52
|
+
- language: yaml
|
|
53
|
+
label: 'Alternative: enable-node-corepack input (setup-node v4.2+)'
|
|
54
|
+
code: |
|
|
55
|
+
- name: Set up Node.js
|
|
56
|
+
uses: actions/setup-node@v4
|
|
57
|
+
with:
|
|
58
|
+
node-version: '20'
|
|
59
|
+
cache: 'yarn'
|
|
60
|
+
enable-node-corepack: true
|
|
61
|
+
prevention:
|
|
62
|
+
- "Always run 'corepack enable' before setup-node when package.json has a 'packageManager' field specifying Yarn 4+"
|
|
63
|
+
- "Verify Corepack is enabled before relying on setup-node's yarn cache integration in Yarn Berry projects"
|
|
64
|
+
- "Pin the Yarn version in .yarnrc.yml in addition to the packageManager field to ensure consistent resolution"
|
|
65
|
+
docs:
|
|
66
|
+
- url: 'https://github.com/actions/setup-node/issues/1027'
|
|
67
|
+
label: 'actions/setup-node#1027 — If cache: yarn is specified, this action fails (38 reactions)'
|
|
68
|
+
- url: 'https://github.com/actions/setup-node/blob/main/docs/advanced-usage.md#corepack'
|
|
69
|
+
label: 'setup-node advanced usage — Corepack support'
|
|
70
|
+
- url: 'https://yarnpkg.com/getting-started/install'
|
|
71
|
+
label: 'Yarn Berry — Installation via Corepack'
|
|
@@ -0,0 +1,69 @@
|
|
|
1
|
+
id: triggers-048
|
|
2
|
+
title: 'Scheduled workflows silently disabled on forked repositories — on.schedule never fires until manually re-enabled in Settings'
|
|
3
|
+
category: triggers
|
|
4
|
+
severity: silent-failure
|
|
5
|
+
tags:
|
|
6
|
+
- schedule
|
|
7
|
+
- fork
|
|
8
|
+
- workflow-disabled
|
|
9
|
+
- cron
|
|
10
|
+
- repository-settings
|
|
11
|
+
patterns:
|
|
12
|
+
- regex: 'Scheduled workflows are disabled for this repository'
|
|
13
|
+
flags: 'i'
|
|
14
|
+
- regex: 'This workflow is disabled'
|
|
15
|
+
flags: 'i'
|
|
16
|
+
error_messages:
|
|
17
|
+
- 'Scheduled workflows are disabled for this repository'
|
|
18
|
+
- 'This workflow is disabled'
|
|
19
|
+
root_cause: |
|
|
20
|
+
When a repository containing scheduled workflows is forked, GitHub automatically disables
|
|
21
|
+
all workflow triggers in the fork. This prevents scheduled CI runs from unexpectedly
|
|
22
|
+
consuming GitHub Actions minutes from the fork owner's account and avoids unintended
|
|
23
|
+
side effects from cloned automation.
|
|
24
|
+
|
|
25
|
+
Scheduled workflows (on.schedule:) stop firing entirely on the fork, even if the workflow
|
|
26
|
+
YAML is correct and the branch is up to date. The workflow appears in the Actions tab and
|
|
27
|
+
can be triggered manually via workflow_dispatch, but on.schedule: events are suppressed.
|
|
28
|
+
|
|
29
|
+
This commonly affects:
|
|
30
|
+
- Contributors forking repos to test or contribute scheduled jobs (e.g., nightly builds,
|
|
31
|
+
dependency updates, scheduled reports)
|
|
32
|
+
- Organizations using forks as part of their branching or release strategy and expecting
|
|
33
|
+
scheduled maintenance tasks to continue
|
|
34
|
+
- CI setups where scheduled smoke tests or integration tests are part of the fork workflow
|
|
35
|
+
|
|
36
|
+
The only indicator is the workflow showing as "disabled" in the Actions tab or in the
|
|
37
|
+
workflow run history, which is easy to miss.
|
|
38
|
+
fix: |
|
|
39
|
+
Navigate to the fork repository and enable workflows manually:
|
|
40
|
+
Settings (fork repo) -> Actions -> General -> Allow all actions and reusable workflows.
|
|
41
|
+
Then enable the specific workflow in the Actions tab by clicking "Enable workflow".
|
|
42
|
+
There is no workflow-level or API-level way to force-enable schedules on a fork automatically.
|
|
43
|
+
fix_code:
|
|
44
|
+
- language: yaml
|
|
45
|
+
label: 'Add workflow_dispatch fallback so contributors can trigger manually on forks'
|
|
46
|
+
code: |
|
|
47
|
+
on:
|
|
48
|
+
# Note: scheduled runs are DISABLED on forked repositories by default.
|
|
49
|
+
# Contributors must enable workflows in Settings -> Actions -> General.
|
|
50
|
+
schedule:
|
|
51
|
+
- cron: '0 2 * * *'
|
|
52
|
+
|
|
53
|
+
# Add workflow_dispatch as a fallback for manual triggering on forks
|
|
54
|
+
workflow_dispatch:
|
|
55
|
+
inputs:
|
|
56
|
+
reason:
|
|
57
|
+
description: 'Reason for manual run (required when testing on a fork)'
|
|
58
|
+
required: false
|
|
59
|
+
default: 'manual trigger'
|
|
60
|
+
|
|
61
|
+
prevention:
|
|
62
|
+
- "Document in CONTRIBUTING.md that scheduled workflows must be manually enabled on forks via Settings -> Actions -> General"
|
|
63
|
+
- "Add workflow_dispatch to all scheduled workflows so contributors can manually trigger them on forks during development"
|
|
64
|
+
- "Use repository_dispatch or workflow_run from the upstream repo to trigger downstream automation instead of relying on fork schedules"
|
|
65
|
+
docs:
|
|
66
|
+
- url: 'https://docs.github.com/en/actions/managing-workflow-runs-and-deployments/managing-workflow-runs/disabling-and-enabling-a-workflow'
|
|
67
|
+
label: 'Disabling and enabling a workflow — GitHub Docs'
|
|
68
|
+
- url: 'https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#schedule'
|
|
69
|
+
label: 'schedule event — GitHub Docs'
|
package/package.json
CHANGED