@htekdev/actions-debugger 1.0.122 → 1.0.123
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,137 @@
|
|
|
1
|
+
id: caching-artifacts-072
|
|
2
|
+
title: 'actions/cache@v5 Restore Rate Limit (429) Silently Treated as Cache Miss'
|
|
3
|
+
category: caching-artifacts
|
|
4
|
+
severity: silent-failure
|
|
5
|
+
tags:
|
|
6
|
+
- cache
|
|
7
|
+
- rate-limit
|
|
8
|
+
- 429
|
|
9
|
+
- restore
|
|
10
|
+
- cache-miss
|
|
11
|
+
- silent-failure
|
|
12
|
+
- v5
|
|
13
|
+
- performance
|
|
14
|
+
patterns:
|
|
15
|
+
- regex: 'Warning: You''ve hit a rate limit, your rate limit will reset in \d+ seconds'
|
|
16
|
+
flags: 'i'
|
|
17
|
+
- regex: 'Failed to restore:.*GetCacheEntryDownloadURL.*Rate [Ll]imited'
|
|
18
|
+
flags: 'i'
|
|
19
|
+
- regex: 'Failed request: \(429\) Too Many Requests: rate limit exceeded'
|
|
20
|
+
flags: 'i'
|
|
21
|
+
error_messages:
|
|
22
|
+
- "Warning: You've hit a rate limit, your rate limit will reset in 18 seconds"
|
|
23
|
+
- "Warning: Failed to restore: Failed to GetCacheEntryDownloadURL: Rate Limited: Failed request: (429) Too Many Requests: rate limit exceeded"
|
|
24
|
+
- "Cache not found for input keys: goofy-b41b01ad3312fe1358359b7522c43860bfdad754166c7f1d385e51766e57b4c0"
|
|
25
|
+
root_cause: |
|
|
26
|
+
When the GitHub cache service rate-limits a cache restore lookup request with HTTP
|
|
27
|
+
429 Too Many Requests, actions/cache@v5 does NOT retry the request. Instead, it
|
|
28
|
+
prints a warning and immediately treats the response as a cache miss, proceeding
|
|
29
|
+
with a full build from scratch.
|
|
30
|
+
|
|
31
|
+
The cache service includes a Retry-After header in the 429 response that tells the
|
|
32
|
+
client exactly how many seconds to wait before retrying (often ≤60 seconds). The
|
|
33
|
+
actions/cache implementation ignores this header entirely — no retry, no backoff,
|
|
34
|
+
no configurable behavior. The job simply never gets its cached dependencies.
|
|
35
|
+
|
|
36
|
+
This is a silent failure in the sense that:
|
|
37
|
+
1. The job succeeds — it just rebuilds everything from scratch.
|
|
38
|
+
2. No annotation or error is surfaced in the Actions UI. Only a Warning line in
|
|
39
|
+
the step log reveals what happened.
|
|
40
|
+
3. The resulting build artifacts are correct, but the CI run takes 2–10x longer
|
|
41
|
+
than expected, masking the real cause.
|
|
42
|
+
|
|
43
|
+
Most commonly triggered in large matrix builds (20+ parallel jobs) where many jobs
|
|
44
|
+
simultaneously query the cache service and collectively exhaust the per-repo or
|
|
45
|
+
per-org cache API rate limit. Also reported on repos with heavy cross-job cache
|
|
46
|
+
sharing patterns.
|
|
47
|
+
|
|
48
|
+
Distinct from caching-artifacts-030 (cache-service-429-upload-ebadf-crash.yml):
|
|
49
|
+
that entry covers 429 during the cache UPLOAD phase which crashes with EBADF.
|
|
50
|
+
This entry covers 429 during the cache RESTORE/lookup phase which silently misses
|
|
51
|
+
— different operation, different error message, different impact, different fix path.
|
|
52
|
+
|
|
53
|
+
Source: actions/cache#1758 (May 2026, open); also reported in
|
|
54
|
+
oxidecomputer/hubris#2535 "CI fails intermittently on Windows while restoring cache"
|
|
55
|
+
(May 2026).
|
|
56
|
+
fix: |
|
|
57
|
+
There is no complete fix — this is an open upstream bug (actions/cache#1758).
|
|
58
|
+
The rate-limit retry path is not implemented in actions/cache. Workarounds:
|
|
59
|
+
|
|
60
|
+
Option 1 — Reduce cache API pressure by staggering matrix jobs:
|
|
61
|
+
|
|
62
|
+
strategy:
|
|
63
|
+
matrix: ...
|
|
64
|
+
max-parallel: 5 # Limit to 5 concurrent jobs instead of all at once
|
|
65
|
+
|
|
66
|
+
This reduces the burst of simultaneous restore calls and lowers the chance of
|
|
67
|
+
hitting the rate limit.
|
|
68
|
+
|
|
69
|
+
Option 2 — Add a retry wrapper using actions/cache's restore-keys cascade:
|
|
70
|
+
|
|
71
|
+
- uses: actions/cache@v5
|
|
72
|
+
id: cache
|
|
73
|
+
with:
|
|
74
|
+
key: ${{ runner.os }}-deps-${{ hashFiles('**/lockfile') }}
|
|
75
|
+
restore-keys: |
|
|
76
|
+
${{ runner.os }}-deps-
|
|
77
|
+
- name: Warn on cache rate limit miss
|
|
78
|
+
if: steps.cache.outputs.cache-hit != 'true'
|
|
79
|
+
run: |
|
|
80
|
+
echo "::warning::Cache miss — may be rate limited. Check step log for 429."
|
|
81
|
+
|
|
82
|
+
Option 3 — Switch to a self-hosted cache backend to bypass GitHub's rate limits:
|
|
83
|
+
|
|
84
|
+
env:
|
|
85
|
+
ACTIONS_CACHE_URL: https://your-cache-backend.example.com/
|
|
86
|
+
ACTIONS_RUNTIME_TOKEN: ${{ secrets.CACHE_TOKEN }}
|
|
87
|
+
|
|
88
|
+
Option 4 — Accept it and add monitoring. If you frequently see the rate limit
|
|
89
|
+
warning, consider filing a support ticket to request a higher cache API rate limit
|
|
90
|
+
for your organization.
|
|
91
|
+
fix_code:
|
|
92
|
+
- language: yaml
|
|
93
|
+
label: 'Reduce parallelism to lower cache restore burst pressure'
|
|
94
|
+
code: |
|
|
95
|
+
jobs:
|
|
96
|
+
build:
|
|
97
|
+
strategy:
|
|
98
|
+
matrix:
|
|
99
|
+
target: [linux-x64, linux-arm64, windows-x64, macos-x64, macos-arm64]
|
|
100
|
+
max-parallel: 4 # Stagger jobs to reduce simultaneous cache restore calls
|
|
101
|
+
steps:
|
|
102
|
+
- uses: actions/cache@v5
|
|
103
|
+
with:
|
|
104
|
+
path: ~/.cargo/registry
|
|
105
|
+
key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}
|
|
106
|
+
|
|
107
|
+
- language: yaml
|
|
108
|
+
label: 'Add explicit warning step to surface rate limit cache misses clearly'
|
|
109
|
+
code: |
|
|
110
|
+
steps:
|
|
111
|
+
- uses: actions/cache@v5
|
|
112
|
+
id: cache-restore
|
|
113
|
+
with:
|
|
114
|
+
path: |
|
|
115
|
+
~/.npm
|
|
116
|
+
node_modules
|
|
117
|
+
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
|
|
118
|
+
restore-keys: |
|
|
119
|
+
${{ runner.os }}-node-
|
|
120
|
+
|
|
121
|
+
- name: Check for cache rate limit miss
|
|
122
|
+
if: steps.cache-restore.outputs.cache-hit != 'true'
|
|
123
|
+
run: |
|
|
124
|
+
echo "::warning::Cache miss detected — check step log for '429 Too Many Requests' to distinguish rate-limit miss from genuine cache absence."
|
|
125
|
+
|
|
126
|
+
prevention:
|
|
127
|
+
- 'Set max-parallel on matrix strategies to limit simultaneous cache restore API calls and avoid triggering the per-org/per-repo cache rate limit.'
|
|
128
|
+
- 'Monitor the cache restore step logs for the warning message "You''ve hit a rate limit" to distinguish rate-limit misses from genuine cache absences when diagnosing slow CI runs.'
|
|
129
|
+
- 'Consider using restore-keys fallback chains so that even a rate-limited primary key miss may still succeed with a partial restore from a broader key.'
|
|
130
|
+
- 'Report rate limit occurrences to GitHub Support with your org name to request a higher cache API rate limit if you encounter this regularly in large workflows.'
|
|
131
|
+
docs:
|
|
132
|
+
- url: 'https://github.com/actions/cache/issues/1758'
|
|
133
|
+
label: 'actions/cache#1758 — Handle rate limit (open, May 2026)'
|
|
134
|
+
- url: 'https://github.com/oxidecomputer/hubris/issues/2535'
|
|
135
|
+
label: 'oxidecomputer/hubris#2535 — CI fails intermittently on Windows while restoring cache (May 2026)'
|
|
136
|
+
- url: 'https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#usage-limits-and-eviction-policy'
|
|
137
|
+
label: 'GitHub Docs — Caching usage limits and eviction policy'
|
|
@@ -0,0 +1,140 @@
|
|
|
1
|
+
id: runner-environment-222
|
|
2
|
+
title: 'Windows Self-Hosted Runner V2 Broker Listener Stops Polling After First Job Completion'
|
|
3
|
+
category: runner-environment
|
|
4
|
+
severity: error
|
|
5
|
+
tags:
|
|
6
|
+
- self-hosted
|
|
7
|
+
- windows
|
|
8
|
+
- broker
|
|
9
|
+
- v2-flow
|
|
10
|
+
- listener
|
|
11
|
+
- polling
|
|
12
|
+
- idle
|
|
13
|
+
- 2.334.0
|
|
14
|
+
- BrokerMessageListener
|
|
15
|
+
patterns:
|
|
16
|
+
- regex: 'BrokerMessageListener.*Get messages has been cancelled using local token source\. Continue to get messages with new status\.'
|
|
17
|
+
flags: 'i'
|
|
18
|
+
- regex: 'BrokerMessageListener.*Received job status event\. JobState: Online'
|
|
19
|
+
flags: 'i'
|
|
20
|
+
error_messages:
|
|
21
|
+
- "[2026-05-21 14:48:13Z INFO BrokerMessageListener] Get messages has been cancelled using local token source. Continue to get messages with new status."
|
|
22
|
+
- "[INFO BrokerMessageListener] Received job status event. JobState: Online"
|
|
23
|
+
- "[INFO BrokerMessageListener] Session created."
|
|
24
|
+
root_cause: |
|
|
25
|
+
On Windows self-hosted runners using the V2 broker protocol (useV2Flow: true,
|
|
26
|
+
serverUrlV2: broker.actions.githubusercontent.com), a race condition in the
|
|
27
|
+
BrokerMessageListener causes the runner to permanently stop polling the broker
|
|
28
|
+
after the first job completes.
|
|
29
|
+
|
|
30
|
+
The sequence that triggers the hang:
|
|
31
|
+
1. Runner starts, creates a broker session, and begins polling for messages.
|
|
32
|
+
2. First job arrives → BrokerMessageListener logs "JobState: Busy".
|
|
33
|
+
3. Job finishes → BrokerMessageListener logs "JobState: Online".
|
|
34
|
+
4. The Online state transition triggers a cancellation of the current polling
|
|
35
|
+
loop via a local token source ("Get messages has been cancelled using
|
|
36
|
+
local token source. Continue to get messages with new status.").
|
|
37
|
+
5. The listener is supposed to create a new polling loop with fresh state, but
|
|
38
|
+
due to a bug in the V2 flow state machine, the new polling loop is never
|
|
39
|
+
started. No further GET /message requests are ever issued.
|
|
40
|
+
|
|
41
|
+
The runner process stays alive. OAuth token refreshes continue on schedule (so
|
|
42
|
+
credentials are not the problem). The runner shows as "Idle" in the GitHub UI.
|
|
43
|
+
However, it will never pick up another job until the service is manually restarted.
|
|
44
|
+
|
|
45
|
+
The bug was introduced in or around v2.334.0 on Windows. It does not affect:
|
|
46
|
+
- Linux runners (different socket layer — see broker-server-socket-exception-nat-timeout-linux.yml)
|
|
47
|
+
- macOS runners (see macos-self-hosted-listener-aad-ghost-busy-stall.yml for a
|
|
48
|
+
separate macOS stall pattern)
|
|
49
|
+
- V1 flow runners (useV2Flow: false)
|
|
50
|
+
- GitHub-hosted runners (not affected by self-hosted listener bugs)
|
|
51
|
+
|
|
52
|
+
Source: actions/runner#4444 (May 2026, open). Reported on Windows Server 2022
|
|
53
|
+
x64, v2.334.0, V2 flow. Three reproducible occurrences in 22 hours on a
|
|
54
|
+
previously stable 6+ day continuous runner.
|
|
55
|
+
fix: |
|
|
56
|
+
Immediate fix — Restart the runner service to recover:
|
|
57
|
+
|
|
58
|
+
Restart-Service actions.runner.*
|
|
59
|
+
|
|
60
|
+
Or via the runner management interface:
|
|
61
|
+
1. Go to repo/org Settings → Actions → Runners
|
|
62
|
+
2. Force-remove the stale runner registration
|
|
63
|
+
3. Re-register and restart
|
|
64
|
+
|
|
65
|
+
Structural workarounds:
|
|
66
|
+
|
|
67
|
+
Option 1 — Switch to ephemeral runners (recommended for most use cases):
|
|
68
|
+
Ephemeral runners register once, run one job, and exit cleanly. No stale state.
|
|
69
|
+
|
|
70
|
+
./config.sh --url https://github.com/ORG/REPO --token TOKEN --ephemeral
|
|
71
|
+
./run.sh
|
|
72
|
+
|
|
73
|
+
Or with Actions Runner Controller (ARC):
|
|
74
|
+
autoscaling.runnerScaleSetListener.minRunners: 1
|
|
75
|
+
|
|
76
|
+
Option 2 — Revert to V1 broker flow if ephemeral is not an option:
|
|
77
|
+
The V1 flow (long-polling, non-broker) does not exhibit this specific hang.
|
|
78
|
+
Edit the .runner config file and set useV2Flow: false, then restart the service.
|
|
79
|
+
Note: V1 is deprecated and will eventually be removed.
|
|
80
|
+
|
|
81
|
+
Option 3 — Add an automatic service recovery watchdog:
|
|
82
|
+
|
|
83
|
+
# Windows Task Scheduler: check every 5 minutes if runner has been Idle >20min
|
|
84
|
+
# and restart the service if it's stuck
|
|
85
|
+
$runner = Get-Service "actions.runner.*"
|
|
86
|
+
if ($runner.Status -eq "Running") {
|
|
87
|
+
# Check last job timestamp via API; if >20min and jobs queued, restart
|
|
88
|
+
Restart-Service "actions.runner.*"
|
|
89
|
+
}
|
|
90
|
+
|
|
91
|
+
Option 4 — Pin to a known-good runner version:
|
|
92
|
+
If v2.334.0+ reliably triggers this, pin the runner to v2.333.x by editing
|
|
93
|
+
the .runner config and disabling auto-update. Note: outdated versions
|
|
94
|
+
eventually stop being able to receive messages.
|
|
95
|
+
fix_code:
|
|
96
|
+
- language: yaml
|
|
97
|
+
label: 'Use ephemeral runners to avoid stale listener state entirely'
|
|
98
|
+
code: |
|
|
99
|
+
# In your workflow:
|
|
100
|
+
jobs:
|
|
101
|
+
build:
|
|
102
|
+
runs-on: [self-hosted, windows-x64] # Labels for your runner pool
|
|
103
|
+
|
|
104
|
+
# Register runners as ephemeral:
|
|
105
|
+
# ./config.cmd --url https://github.com/ORG/REPO --token TOKEN --ephemeral
|
|
106
|
+
# Each runner exits after completing one job; a process manager (NSSM, task
|
|
107
|
+
# scheduler, or ARC) restarts it to accept the next job.
|
|
108
|
+
|
|
109
|
+
- language: yaml
|
|
110
|
+
label: 'Add watchdog step to detect stale listener symptom (queue depth check)'
|
|
111
|
+
code: |
|
|
112
|
+
# Optional diagnostic: surface "no runners picked up job for >N minutes" via API
|
|
113
|
+
# Run this in a separate monitoring workflow:
|
|
114
|
+
jobs:
|
|
115
|
+
watchdog:
|
|
116
|
+
runs-on: ubuntu-latest
|
|
117
|
+
steps:
|
|
118
|
+
- name: Check for stuck self-hosted Windows runners
|
|
119
|
+
env:
|
|
120
|
+
GH_TOKEN: ${{ secrets.RUNNER_ADMIN_PAT }}
|
|
121
|
+
run: |
|
|
122
|
+
# List queued jobs older than 10 minutes that are assigned to self-hosted
|
|
123
|
+
gh api repos/${{ github.repository }}/actions/runs \
|
|
124
|
+
--jq '.workflow_runs[] | select(.status=="queued") | .id' \
|
|
125
|
+
| while read run_id; do
|
|
126
|
+
echo "Queued run: $run_id"
|
|
127
|
+
done
|
|
128
|
+
|
|
129
|
+
prevention:
|
|
130
|
+
- 'Use ephemeral self-hosted runners — they register, run one job, and exit. No stale listener state can accumulate.'
|
|
131
|
+
- 'If using long-lived runners on Windows with V2 broker flow, add monitoring to detect runners stuck in the Idle state with queued jobs.'
|
|
132
|
+
- 'Set up automatic service recovery for the runner service on Windows (e.g., via Windows Service recovery actions: restart after 1st failure).'
|
|
133
|
+
- 'Monitor actions/runner release notes for a fix to the V2 listener polling regression introduced around v2.334.0.'
|
|
134
|
+
docs:
|
|
135
|
+
- url: 'https://github.com/actions/runner/issues/4444'
|
|
136
|
+
label: 'actions/runner#4444 — Listener stops polling broker after first job''s Busy→Online transition (2.334.0, Windows, V2 flow)'
|
|
137
|
+
- url: 'https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/running-scripts-before-or-after-a-job'
|
|
138
|
+
label: 'GitHub Docs — Self-hosted runner configuration'
|
|
139
|
+
- url: 'https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/autoscaling-with-self-hosted-runners'
|
|
140
|
+
label: 'GitHub Docs — Autoscaling with self-hosted runners (ephemeral runner pattern)'
|
|
@@ -0,0 +1,149 @@
|
|
|
1
|
+
id: runner-environment-223
|
|
2
|
+
title: 'macOS-15 Arm64 brew update Fails with Stale lockf Lock When Run Twice'
|
|
3
|
+
category: runner-environment
|
|
4
|
+
severity: error
|
|
5
|
+
tags:
|
|
6
|
+
- macos
|
|
7
|
+
- homebrew
|
|
8
|
+
- brew-update
|
|
9
|
+
- lockf
|
|
10
|
+
- arm64
|
|
11
|
+
- macos-15
|
|
12
|
+
- regression
|
|
13
|
+
- concurrent
|
|
14
|
+
patterns:
|
|
15
|
+
- regex: 'lockf: 200: already locked'
|
|
16
|
+
flags: 'i'
|
|
17
|
+
- regex: 'Error: Another `brew update` process is already running\.'
|
|
18
|
+
flags: 'i'
|
|
19
|
+
- regex: 'lockf:.*already locked\s*\nError: Another.*brew update.*process is already running'
|
|
20
|
+
flags: 'im'
|
|
21
|
+
error_messages:
|
|
22
|
+
- "lockf: 200: already locked"
|
|
23
|
+
- "Error: Another `brew update` process is already running."
|
|
24
|
+
- "Please wait for it to finish or terminate it to continue."
|
|
25
|
+
- "Error: Process completed with exit code 1."
|
|
26
|
+
root_cause: |
|
|
27
|
+
On macOS-15 Arm64 GitHub Actions hosted runners starting with image version
|
|
28
|
+
20260422.526 (released ~April 22, 2026), running `brew update` more than once
|
|
29
|
+
within the same workflow — or across two steps that both call `brew update` —
|
|
30
|
+
fails on the second invocation with a stale lockf lock error.
|
|
31
|
+
|
|
32
|
+
Homebrew uses a lockfile at `/opt/homebrew/Library/Taps/homebrew/homebrew-core/.git/index.lock`
|
|
33
|
+
(or a similar path) to prevent concurrent updates. In the affected image versions,
|
|
34
|
+
the first `brew update` completes successfully but leaves the lock file in a
|
|
35
|
+
state that subsequent `brew update` calls cannot acquire. The `lockf` system
|
|
36
|
+
call returns errno 200 (EDEADLK on macOS), which Homebrew surfaces as
|
|
37
|
+
"Another brew update process is already running."
|
|
38
|
+
|
|
39
|
+
This is a regression — the same workflow step pattern worked correctly on image
|
|
40
|
+
version 20260415.520 and earlier.
|
|
41
|
+
|
|
42
|
+
Common trigger patterns:
|
|
43
|
+
1. Explicit double-update in a single step: `brew update && brew update`
|
|
44
|
+
2. Two separate steps that each call `brew update` before installing different tools
|
|
45
|
+
3. Parallel jobs on the same runner image that both run `brew update` (less common
|
|
46
|
+
since each hosted runner job gets a fresh VM, but affects matrix jobs in the
|
|
47
|
+
same workflow when they share a Homebrew setup step via the action cache)
|
|
48
|
+
4. A step script that calls `brew update` internally AND the user also calls it
|
|
49
|
+
|
|
50
|
+
Note: This affects macOS-15 Arm64 specifically. macOS-14, macOS-26, and x86_64
|
|
51
|
+
variants were NOT marked as affected in the original bug report (runner-images#13965).
|
|
52
|
+
|
|
53
|
+
Source: actions/runner-images#13965 (April 2026, open, under investigation by
|
|
54
|
+
GitHub runner-images team). Reported with reproducible case from the
|
|
55
|
+
mullvad/mullvadvpn-app CI pipeline.
|
|
56
|
+
fix: |
|
|
57
|
+
Option 1 — Run brew update only once per job (preferred):
|
|
58
|
+
|
|
59
|
+
Consolidate all your brew installations into a single step and call brew update
|
|
60
|
+
exactly once before them:
|
|
61
|
+
|
|
62
|
+
- name: Install dependencies
|
|
63
|
+
run: |
|
|
64
|
+
brew update
|
|
65
|
+
brew install cmake ninja pkg-config
|
|
66
|
+
|
|
67
|
+
Option 2 — Use HOMEBREW_NO_AUTO_UPDATE=1 on steps that don't need fresh formulae:
|
|
68
|
+
|
|
69
|
+
If you only need brew update for specific steps, set the env var on all other
|
|
70
|
+
brew-using steps to prevent automatic update attempts:
|
|
71
|
+
|
|
72
|
+
- name: Install specific tool
|
|
73
|
+
env:
|
|
74
|
+
HOMEBREW_NO_AUTO_UPDATE: '1'
|
|
75
|
+
run: brew install your-tool # Skips the implicit brew update
|
|
76
|
+
|
|
77
|
+
Option 3 — Guard the second brew update with a lock check:
|
|
78
|
+
|
|
79
|
+
- name: Safe brew update
|
|
80
|
+
run: |
|
|
81
|
+
flock -xn /opt/homebrew/Library/Taps/homebrew/homebrew-core/.git/index.lock \
|
|
82
|
+
brew update || echo "::warning::brew update skipped (lock already held)"
|
|
83
|
+
|
|
84
|
+
Option 4 — Use brew upgrade instead of repeated brew update:
|
|
85
|
+
If you need the latest formula versions, run brew update once and then
|
|
86
|
+
use brew upgrade to update installed packages:
|
|
87
|
+
|
|
88
|
+
- name: Update and upgrade Homebrew
|
|
89
|
+
run: |
|
|
90
|
+
brew update # Run exactly once
|
|
91
|
+
brew upgrade # Upgrades installed formulae to latest
|
|
92
|
+
|
|
93
|
+
Option 5 — Check for the regression in your image version and pin:
|
|
94
|
+
If you need to pin to a known-good image version while the fix is pending,
|
|
95
|
+
see GitHub's runner-images documentation for image version pinning options
|
|
96
|
+
(note: pinning is not officially supported for GitHub-hosted standard runners).
|
|
97
|
+
fix_code:
|
|
98
|
+
- language: yaml
|
|
99
|
+
label: 'Broken — two brew update calls in same workflow (second fails on affected image)'
|
|
100
|
+
code: |
|
|
101
|
+
# This fails on macOS-15 Arm64 image 20260422.526+ with lockf: 200: already locked:
|
|
102
|
+
steps:
|
|
103
|
+
- name: Install build tools
|
|
104
|
+
run: |
|
|
105
|
+
brew update
|
|
106
|
+
brew install cmake ninja
|
|
107
|
+
|
|
108
|
+
- name: Install test tools
|
|
109
|
+
run: |
|
|
110
|
+
brew update # FAILS: Another brew update process is already running
|
|
111
|
+
brew install lcov
|
|
112
|
+
|
|
113
|
+
- language: yaml
|
|
114
|
+
label: 'Fixed — single brew update before consolidated installs'
|
|
115
|
+
code: |
|
|
116
|
+
# Consolidate into one brew update call at the start:
|
|
117
|
+
steps:
|
|
118
|
+
- name: Install all Homebrew tools
|
|
119
|
+
run: |
|
|
120
|
+
brew update # Only call once per job
|
|
121
|
+
brew install cmake ninja lcov
|
|
122
|
+
|
|
123
|
+
- language: yaml
|
|
124
|
+
label: 'Fixed — use HOMEBREW_NO_AUTO_UPDATE=1 on subsequent brew steps'
|
|
125
|
+
code: |
|
|
126
|
+
# Or prevent auto-update on steps after the first:
|
|
127
|
+
steps:
|
|
128
|
+
- name: Install build tools
|
|
129
|
+
run: |
|
|
130
|
+
brew update
|
|
131
|
+
brew install cmake ninja
|
|
132
|
+
|
|
133
|
+
- name: Install test tools (no re-update needed)
|
|
134
|
+
env:
|
|
135
|
+
HOMEBREW_NO_AUTO_UPDATE: '1'
|
|
136
|
+
run: brew install lcov # Uses existing formula cache; no brew update call
|
|
137
|
+
|
|
138
|
+
prevention:
|
|
139
|
+
- 'Call brew update at most once per job. Consolidate all Homebrew installations into a single step with one brew update at the top.'
|
|
140
|
+
- 'Set HOMEBREW_NO_AUTO_UPDATE=1 as a job-level env var and call brew update explicitly only in the one step that needs it.'
|
|
141
|
+
- 'Pin to macOS-14 (macos-14-xlarge) or use macOS-26 (which has different Homebrew behavior) if the regression is blocking critical workflows while runner-images#13965 is open.'
|
|
142
|
+
- 'Check your CI logs for the "lockf: 200: already locked" error if macOS-15 Arm64 workflows started failing around late April 2026 — this regression is the likely cause.'
|
|
143
|
+
docs:
|
|
144
|
+
- url: 'https://github.com/actions/runner-images/issues/13965'
|
|
145
|
+
label: 'actions/runner-images#13965 — Running brew update twice in one workflow breaks (open, April 2026)'
|
|
146
|
+
- url: 'https://docs.brew.sh/Manpage#environment'
|
|
147
|
+
label: 'Homebrew docs — HOMEBREW_NO_AUTO_UPDATE environment variable'
|
|
148
|
+
- url: 'https://github.com/mullvad/mullvadvpn-app/actions/runs/24890005834'
|
|
149
|
+
label: 'mullvad/mullvadvpn-app — Example failing run (regression confirmed between image 20260415 and 20260422)'
|
package/package.json
CHANGED