@htekdev/actions-debugger 1.0.89 → 1.0.90
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,95 @@
|
|
|
1
|
+
id: concurrency-timing-044
|
|
2
|
+
title: 'Matrix jobs with a static concurrency group key serialize instead of running in parallel'
|
|
3
|
+
category: concurrency-timing
|
|
4
|
+
severity: silent-failure
|
|
5
|
+
tags:
|
|
6
|
+
- matrix
|
|
7
|
+
- concurrency
|
|
8
|
+
- parallelism
|
|
9
|
+
- group-key
|
|
10
|
+
- strategy
|
|
11
|
+
patterns:
|
|
12
|
+
- regex: 'Waiting for a pending job to finish'
|
|
13
|
+
flags: 'i'
|
|
14
|
+
- regex: 'This workflow is waiting for a pending job to complete'
|
|
15
|
+
flags: 'i'
|
|
16
|
+
error_messages:
|
|
17
|
+
- 'Waiting for a pending job to finish — concurrency: ci-deploy'
|
|
18
|
+
root_cause: |
|
|
19
|
+
When a workflow-level or job-level concurrency group is configured with a static
|
|
20
|
+
key that does not include the matrix dimension values, all matrix legs share the
|
|
21
|
+
same concurrency slot. GitHub Actions enforces that only one run occupies each
|
|
22
|
+
slot at a time, so instead of running N matrix legs in parallel, the legs queue
|
|
23
|
+
and execute one at a time — silently serializing a job strategy that was intended
|
|
24
|
+
to be parallel.
|
|
25
|
+
|
|
26
|
+
This can multiply workflow duration by the number of matrix dimensions (e.g., a
|
|
27
|
+
3-OS matrix that should finish in 10 minutes takes 30 minutes). The GitHub Actions
|
|
28
|
+
UI shows later matrix legs as "Waiting for a pending job to finish" which hints at
|
|
29
|
+
the problem, but developers often interpret this as runner resource contention rather
|
|
30
|
+
than a concurrency group misconfiguration.
|
|
31
|
+
|
|
32
|
+
Common patterns that trigger this:
|
|
33
|
+
concurrency:
|
|
34
|
+
group: ci-${{ github.ref }} # all matrix legs share "ci-refs/heads/main"
|
|
35
|
+
|
|
36
|
+
concurrency:
|
|
37
|
+
group: ${{ github.workflow }} # all legs share workflow name
|
|
38
|
+
fix: |
|
|
39
|
+
Include the relevant matrix dimension values in the concurrency group key so that
|
|
40
|
+
each matrix leg gets a unique slot. If cancel-in-progress behavior is still needed,
|
|
41
|
+
it will apply per-matrix-leg rather than globally across all legs.
|
|
42
|
+
|
|
43
|
+
If you intentionally want to serialize matrix legs (e.g., sequential deploys to
|
|
44
|
+
environments), keep the static key but document the serialization intent.
|
|
45
|
+
fix_code:
|
|
46
|
+
- language: yaml
|
|
47
|
+
label: 'Include matrix values in concurrency group key'
|
|
48
|
+
code: |
|
|
49
|
+
jobs:
|
|
50
|
+
test:
|
|
51
|
+
strategy:
|
|
52
|
+
matrix:
|
|
53
|
+
os: [ubuntu-latest, windows-latest, macos-latest]
|
|
54
|
+
node: [18, 20, 22]
|
|
55
|
+
runs-on: ${{ matrix.os }}
|
|
56
|
+
concurrency:
|
|
57
|
+
# Unique slot per matrix leg — allows full parallelism
|
|
58
|
+
group: ci-${{ github.ref }}-${{ matrix.os }}-${{ matrix.node }}
|
|
59
|
+
cancel-in-progress: true
|
|
60
|
+
steps:
|
|
61
|
+
- uses: actions/checkout@v4
|
|
62
|
+
- uses: actions/setup-node@v4
|
|
63
|
+
with:
|
|
64
|
+
node-version: ${{ matrix.node }}
|
|
65
|
+
- run: npm test
|
|
66
|
+
- language: yaml
|
|
67
|
+
label: 'Workflow-level concurrency must also include matrix values'
|
|
68
|
+
code: |
|
|
69
|
+
# BAD: workflow-level concurrency applies to ALL jobs, including matrix legs
|
|
70
|
+
# concurrency:
|
|
71
|
+
# group: ci-${{ github.ref }} # serializes all legs!
|
|
72
|
+
# cancel-in-progress: true
|
|
73
|
+
|
|
74
|
+
# GOOD: set concurrency at the job level with matrix dimensions in the key
|
|
75
|
+
jobs:
|
|
76
|
+
build:
|
|
77
|
+
strategy:
|
|
78
|
+
matrix:
|
|
79
|
+
platform: [linux, windows, macos]
|
|
80
|
+
runs-on: ubuntu-latest
|
|
81
|
+
concurrency:
|
|
82
|
+
group: build-${{ github.ref }}-${{ matrix.platform }}
|
|
83
|
+
cancel-in-progress: true
|
|
84
|
+
steps:
|
|
85
|
+
- run: echo "Building for ${{ matrix.platform }}"
|
|
86
|
+
prevention:
|
|
87
|
+
- 'Always include matrix dimension values in concurrency group keys: group: ci-${{ github.ref }}-${{ matrix.os }}'
|
|
88
|
+
- 'Check workflow execution time after adding concurrency groups — unexpected serialization increases total duration'
|
|
89
|
+
- 'Use workflow-level concurrency only for single-job workflows; for matrix jobs, always configure concurrency at the job level'
|
|
90
|
+
- 'Verify parallelism by checking the GitHub Actions timeline view — all matrix legs should show overlapping execution'
|
|
91
|
+
docs:
|
|
92
|
+
- url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/using-concurrency'
|
|
93
|
+
label: 'Using concurrency in GitHub Actions'
|
|
94
|
+
- url: 'https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix'
|
|
95
|
+
label: 'Matrix strategy syntax reference'
|
|
@@ -0,0 +1,119 @@
|
|
|
1
|
+
id: known-unsolved-052
|
|
2
|
+
title: 'GitHub-hosted runner IP addresses change on every workflow run — static IP allowlisting unreliable'
|
|
3
|
+
category: known-unsolved
|
|
4
|
+
severity: limitation
|
|
5
|
+
tags:
|
|
6
|
+
- runner
|
|
7
|
+
- ip-address
|
|
8
|
+
- firewall
|
|
9
|
+
- allowlist
|
|
10
|
+
- network
|
|
11
|
+
- hosted-runner
|
|
12
|
+
patterns:
|
|
13
|
+
- regex: 'Connection refused|Connection timed out|Unable to connect'
|
|
14
|
+
flags: 'i'
|
|
15
|
+
- regex: 'connect ECONNREFUSED|ECONNRESET|ETIMEDOUT'
|
|
16
|
+
flags: 'i'
|
|
17
|
+
- regex: 'blocked by firewall|access denied.*firewall|ip.*not.*allowed'
|
|
18
|
+
flags: 'i'
|
|
19
|
+
error_messages:
|
|
20
|
+
- 'Error: connect ECONNREFUSED 10.0.0.5:5432'
|
|
21
|
+
- 'curl: (7) Failed to connect to internal-api.company.com port 443: Connection refused'
|
|
22
|
+
- 'Error: connect ETIMEDOUT'
|
|
23
|
+
root_cause: |
|
|
24
|
+
GitHub-hosted runners are allocated from a large, rotating pool of virtual machines.
|
|
25
|
+
The IP address assigned to each run is drawn from GitHub's published CIDR ranges
|
|
26
|
+
(available via https://api.github.com/meta under "actions") but changes on every
|
|
27
|
+
workflow run — there is no way to obtain a stable, predictable IP for a GitHub-hosted
|
|
28
|
+
runner in advance.
|
|
29
|
+
|
|
30
|
+
GitHub publishes these IP ranges for documentation purposes, but:
|
|
31
|
+
1. The ranges are broad (/20 or larger) and overlap with other GitHub services
|
|
32
|
+
2. The specific IP within the range cannot be predicted before the run starts
|
|
33
|
+
3. The ranges update periodically, requiring allowlist maintenance
|
|
34
|
+
4. On each run, the runner's IP can be any address in the published ranges
|
|
35
|
+
|
|
36
|
+
This makes static IP allowlisting in external firewalls, database security groups
|
|
37
|
+
(AWS RDS, Azure SQL, Cloudflare), or on-premise systems unreliable. Allowlisting the
|
|
38
|
+
entire published range exposes hundreds of thousands of IP addresses and violates
|
|
39
|
+
least-privilege security principles.
|
|
40
|
+
|
|
41
|
+
This is a fundamental architecture constraint of GitHub-hosted runners and has no
|
|
42
|
+
perfect solution — only workarounds.
|
|
43
|
+
fix: |
|
|
44
|
+
There is no way to guarantee a stable IP for GitHub-hosted runners. Use one of these
|
|
45
|
+
patterns instead of IP allowlisting:
|
|
46
|
+
|
|
47
|
+
1. OIDC (preferred): Use OIDC tokens to authenticate to cloud providers (AWS, Azure,
|
|
48
|
+
GCP) rather than network-level access controls. No IP allowlisting needed.
|
|
49
|
+
|
|
50
|
+
2. Self-hosted runners: Deploy runners on your network with known, stable IPs.
|
|
51
|
+
|
|
52
|
+
3. Dynamic allowlisting: At workflow start, call your cloud provider API to add the
|
|
53
|
+
runner's current IP to the security group; remove it at workflow end. Brittle but
|
|
54
|
+
workable for database access.
|
|
55
|
+
|
|
56
|
+
4. VPN/tunnel action: Use actions like cloudflare/cloudflare-warp-action or a
|
|
57
|
+
WireGuard setup action to tunnel runner traffic through a fixed gateway IP.
|
|
58
|
+
|
|
59
|
+
5. Private hosted runners (GitHub Enterprise): If on GHEC, configure static IP ranges
|
|
60
|
+
via network configurations for GitHub-hosted runners.
|
|
61
|
+
fix_code:
|
|
62
|
+
- language: yaml
|
|
63
|
+
label: 'Use OIDC authentication instead of IP allowlisting (AWS example)'
|
|
64
|
+
code: |
|
|
65
|
+
jobs:
|
|
66
|
+
deploy:
|
|
67
|
+
runs-on: ubuntu-latest
|
|
68
|
+
permissions:
|
|
69
|
+
id-token: write
|
|
70
|
+
contents: read
|
|
71
|
+
steps:
|
|
72
|
+
- uses: aws-actions/configure-aws-credentials@v4
|
|
73
|
+
with:
|
|
74
|
+
role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
|
|
75
|
+
aws-region: us-east-1
|
|
76
|
+
# No IP allowlisting needed — OIDC validates the token, not the IP
|
|
77
|
+
- run: aws rds describe-db-instances
|
|
78
|
+
- language: yaml
|
|
79
|
+
label: 'Dynamic security group allowlisting (temporary, for legacy systems)'
|
|
80
|
+
code: |
|
|
81
|
+
jobs:
|
|
82
|
+
test-with-db:
|
|
83
|
+
runs-on: ubuntu-latest
|
|
84
|
+
steps:
|
|
85
|
+
- name: Get runner IP
|
|
86
|
+
id: ip
|
|
87
|
+
run: echo "ip=$(curl -s https://api.ipify.org)" >> $GITHUB_OUTPUT
|
|
88
|
+
|
|
89
|
+
- name: Add runner IP to DB security group
|
|
90
|
+
run: |
|
|
91
|
+
aws ec2 authorize-security-group-ingress \
|
|
92
|
+
--group-id sg-0abc123 \
|
|
93
|
+
--protocol tcp \
|
|
94
|
+
--port 5432 \
|
|
95
|
+
--cidr "${{ steps.ip.outputs.ip }}/32"
|
|
96
|
+
|
|
97
|
+
- name: Run tests
|
|
98
|
+
run: npm test
|
|
99
|
+
|
|
100
|
+
- name: Remove runner IP from security group
|
|
101
|
+
if: always()
|
|
102
|
+
run: |
|
|
103
|
+
aws ec2 revoke-security-group-ingress \
|
|
104
|
+
--group-id sg-0abc123 \
|
|
105
|
+
--protocol tcp \
|
|
106
|
+
--port 5432 \
|
|
107
|
+
--cidr "${{ steps.ip.outputs.ip }}/32"
|
|
108
|
+
prevention:
|
|
109
|
+
- 'Design CI pipelines to use token-based authentication (OIDC, API keys, mTLS) rather than IP allowlisting from the start'
|
|
110
|
+
- 'For AWS: use IAM roles with OIDC (aws-actions/configure-aws-credentials); for Azure: use azure/login with OIDC; for GCP: use google-github-actions/auth with Workload Identity Federation'
|
|
111
|
+
- 'If IP allowlisting is unavoidable, use GitHub Enterprise Cloud with a configured network allowing stable egress IPs'
|
|
112
|
+
- 'Subscribe to GitHub changelog for updates to runner IP range publications — the ranges do expand over time'
|
|
113
|
+
docs:
|
|
114
|
+
- url: 'https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners#ip-addresses'
|
|
115
|
+
label: 'GitHub-hosted runner IP addresses'
|
|
116
|
+
- url: 'https://api.github.com/meta'
|
|
117
|
+
label: 'GitHub meta API — published actions IP ranges'
|
|
118
|
+
- url: 'https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-cloud-providers'
|
|
119
|
+
label: 'Configuring OIDC in cloud providers'
|
|
@@ -0,0 +1,69 @@
|
|
|
1
|
+
id: silent-failures-085
|
|
2
|
+
title: 'actions/checkout does not initialize submodules by default — empty submodule directories silently break builds'
|
|
3
|
+
category: silent-failures
|
|
4
|
+
severity: silent-failure
|
|
5
|
+
tags:
|
|
6
|
+
- checkout
|
|
7
|
+
- submodules
|
|
8
|
+
- git-submodule
|
|
9
|
+
- empty-directory
|
|
10
|
+
- build-failure
|
|
11
|
+
patterns:
|
|
12
|
+
- regex: 'fatal: not a git repository'
|
|
13
|
+
flags: 'i'
|
|
14
|
+
- regex: 'No such file or directory'
|
|
15
|
+
flags: 'i'
|
|
16
|
+
- regex: 'cannot open.*No such file or directory'
|
|
17
|
+
flags: 'i'
|
|
18
|
+
error_messages:
|
|
19
|
+
- 'fatal: not a git repository (or any of the parent directories): .git'
|
|
20
|
+
- 'CMake Error: The source directory "/home/runner/work/repo/vendor/lib" does not appear to contain CMakeLists.txt.'
|
|
21
|
+
- 'error: cannot open include file: ../vendor/lib/include/lib.h: No such file or directory'
|
|
22
|
+
root_cause: |
|
|
23
|
+
actions/checkout defaults to submodules: false, meaning any Git submodules
|
|
24
|
+
defined in .gitmodules are NOT cloned — they appear as empty directories in the
|
|
25
|
+
workspace. There is no warning or error in the checkout step output; it completes
|
|
26
|
+
successfully with exit code 0.
|
|
27
|
+
|
|
28
|
+
Downstream build steps that depend on submodule content then fail with generic
|
|
29
|
+
"file not found" or "not a git repository" errors that point to the submodule
|
|
30
|
+
directory, not to the checkout configuration. This mismatch between where the error
|
|
31
|
+
appears (the build step) and its root cause (the checkout step) makes it
|
|
32
|
+
time-consuming to diagnose, especially for contributors unfamiliar with the repo's
|
|
33
|
+
submodule structure.
|
|
34
|
+
|
|
35
|
+
Affected scenarios include:
|
|
36
|
+
- CMake projects with vendored dependencies as submodules
|
|
37
|
+
- Projects using git submodule for shared library code
|
|
38
|
+
- Repos with submodules for test fixtures or documentation themes
|
|
39
|
+
fix: |
|
|
40
|
+
Add submodules: true (or submodules: 'recursive' for nested submodules) to your
|
|
41
|
+
actions/checkout step. For private submodules, you may also need to set
|
|
42
|
+
token: with a PAT that has access to the submodule repositories — the default
|
|
43
|
+
GITHUB_TOKEN only has access to the current repository.
|
|
44
|
+
fix_code:
|
|
45
|
+
- language: yaml
|
|
46
|
+
label: 'Initialize submodules during checkout'
|
|
47
|
+
code: |
|
|
48
|
+
- uses: actions/checkout@v4
|
|
49
|
+
with:
|
|
50
|
+
submodules: true # 'true' for one level, 'recursive' for nested
|
|
51
|
+
# For private submodule repos, provide a PAT with access:
|
|
52
|
+
# token: ${{ secrets.SUBMODULE_PAT }}
|
|
53
|
+
- language: yaml
|
|
54
|
+
label: 'Recursive submodules for nested submodule trees'
|
|
55
|
+
code: |
|
|
56
|
+
- uses: actions/checkout@v4
|
|
57
|
+
with:
|
|
58
|
+
submodules: 'recursive'
|
|
59
|
+
fetch-depth: 0 # Full history if submodule pinning requires it
|
|
60
|
+
prevention:
|
|
61
|
+
- 'Add submodules: true to actions/checkout in all workflows that build code depending on submodule content'
|
|
62
|
+
- 'Add a verification step after checkout to confirm critical submodule paths are non-empty: test -f vendor/lib/README.md'
|
|
63
|
+
- 'Document submodule requirements in your repo README and CONTRIBUTING.md'
|
|
64
|
+
- 'If the submodule repo is private, use a GitHub App token or fine-grained PAT — the default GITHUB_TOKEN cannot access other repositories'
|
|
65
|
+
docs:
|
|
66
|
+
- url: 'https://github.com/actions/checkout#usage'
|
|
67
|
+
label: 'actions/checkout — submodules input reference'
|
|
68
|
+
- url: 'https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/using-submodules-in-workflows'
|
|
69
|
+
label: 'Using submodules in GitHub Actions workflows'
|
|
@@ -0,0 +1,86 @@
|
|
|
1
|
+
id: triggers-060
|
|
2
|
+
title: 'pull_request workflow not re-triggered when PR title or description is edited'
|
|
3
|
+
category: triggers
|
|
4
|
+
severity: silent-failure
|
|
5
|
+
tags:
|
|
6
|
+
- pull_request
|
|
7
|
+
- edited
|
|
8
|
+
- pr-title
|
|
9
|
+
- types
|
|
10
|
+
- conventional-commits
|
|
11
|
+
- status-check
|
|
12
|
+
patterns:
|
|
13
|
+
- regex: 'on:\s*\n\s*pull_request:\s*\n(?:(?!\s*types:).*\n)*'
|
|
14
|
+
flags: 'ms'
|
|
15
|
+
error_messages: []
|
|
16
|
+
root_cause: |
|
|
17
|
+
The default pull_request event types are [opened, synchronize, reopened]. The
|
|
18
|
+
"edited" activity type — which fires when the PR title, body, or base branch is
|
|
19
|
+
changed — is NOT included in the default set. Workflows that validate PR titles
|
|
20
|
+
(e.g., enforcing Conventional Commits format, ticket-number requirements, or length
|
|
21
|
+
limits) will never re-run when a contributor fixes the PR title after an initial
|
|
22
|
+
failure.
|
|
23
|
+
|
|
24
|
+
This creates a persistent UX problem: the required status check shows as failed
|
|
25
|
+
after the title is corrected, and the PR cannot be merged without manually
|
|
26
|
+
re-running the workflow or pushing a new commit. The fix is visible in the GitHub
|
|
27
|
+
UI and source, but the root cause is non-obvious — nothing in the failure log
|
|
28
|
+
indicates the workflow won't respond to a title edit.
|
|
29
|
+
fix: |
|
|
30
|
+
Add "edited" to the pull_request types list for any workflow that validates PR
|
|
31
|
+
metadata (title, description, or target branch). The "edited" type also fires on
|
|
32
|
+
body changes and base branch changes, which is typically harmless for title-checking
|
|
33
|
+
workflows. Do not add "edited" to workflows that trigger expensive CI operations
|
|
34
|
+
unless you intend them to run on every title/body change.
|
|
35
|
+
fix_code:
|
|
36
|
+
- language: yaml
|
|
37
|
+
label: 'Add edited type to re-run on PR title changes'
|
|
38
|
+
code: |
|
|
39
|
+
on:
|
|
40
|
+
pull_request:
|
|
41
|
+
types:
|
|
42
|
+
- opened
|
|
43
|
+
- synchronize
|
|
44
|
+
- reopened
|
|
45
|
+
- edited # Re-run when PR title or description is changed
|
|
46
|
+
|
|
47
|
+
jobs:
|
|
48
|
+
lint-pr-title:
|
|
49
|
+
runs-on: ubuntu-latest
|
|
50
|
+
steps:
|
|
51
|
+
- uses: amannn/action-semantic-pull-request@v5
|
|
52
|
+
env:
|
|
53
|
+
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
|
54
|
+
- language: yaml
|
|
55
|
+
label: 'Conditional execution — only validate title on edited events'
|
|
56
|
+
code: |
|
|
57
|
+
on:
|
|
58
|
+
pull_request:
|
|
59
|
+
types: [opened, synchronize, reopened, edited]
|
|
60
|
+
|
|
61
|
+
jobs:
|
|
62
|
+
check-title:
|
|
63
|
+
runs-on: ubuntu-latest
|
|
64
|
+
steps:
|
|
65
|
+
- name: Validate PR title format
|
|
66
|
+
if: >
|
|
67
|
+
github.event_name == 'pull_request' &&
|
|
68
|
+
(github.event.action == 'opened' ||
|
|
69
|
+
github.event.action == 'edited' ||
|
|
70
|
+
github.event.action == 'reopened')
|
|
71
|
+
run: |
|
|
72
|
+
TITLE="${{ github.event.pull_request.title }}"
|
|
73
|
+
if ! echo "$TITLE" | grep -qP '^(feat|fix|docs|chore|refactor|test|ci)(\(.+\))?: .+'; then
|
|
74
|
+
echo "PR title does not follow Conventional Commits format: $TITLE"
|
|
75
|
+
exit 1
|
|
76
|
+
fi
|
|
77
|
+
prevention:
|
|
78
|
+
- 'Always include "edited" in pull_request types when the workflow validates PR title or description format'
|
|
79
|
+
- 'Test that your PR title validation workflow re-runs when you edit the title — do not assume it does'
|
|
80
|
+
- 'Document required PR title format in CONTRIBUTING.md so contributors know title edits (not just new commits) trigger re-checks'
|
|
81
|
+
- 'Consider adding a job summary or annotation with the exact format requirement when validation fails'
|
|
82
|
+
docs:
|
|
83
|
+
- url: 'https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request'
|
|
84
|
+
label: 'pull_request event — activity types reference'
|
|
85
|
+
- url: 'https://github.com/amannn/action-semantic-pull-request'
|
|
86
|
+
label: 'action-semantic-pull-request (popular PR title lint action)'
|
package/package.json
CHANGED