fix(ci): shellcheck-arm64-pilot runs-on label matches Mac mini's actual registration #1679

Merged

agent-dev-a merged 3 commits from fix-shellcheck-arm64-pilot-runner-label into main 2026-05-26 16:39:48 +00:00

Conversation 4 Commits 3 Files Changed 1

+28 -5

3 Commits

Author	SHA1	Message	Date
Molecule AI Dev Engineer A (Kimi)	9c0b81bf11	Merge branch 'main' into fix-shellcheck-arm64-pilot-runner-label ... # Conflicts: # .gitea/workflows/lint-shellcheck-arm64-pilot.yml	2026-05-26 11:18:50 +00:00
cp-be	1e606494ad	fix(ci): shellcheck-arm64-pilot — Bash 3.2 portable file enumeration ... Run 79275 / task 145654 on Mac mini runner empirically failed at: workflow/3.sh: line 6: mapfile: command not found Process completed with exit code 127 macOS ships Bash 3.2 (Apple license — won't update to GPLv3+ Bash 4+). `mapfile` is a Bash 4+ builtin; not available on Mac mini's /bin/bash. Earlier steps confirmed the Mac mini runner picks up the job correctly (uname -m = arm64, kernel Darwin 23.5.0, "arm64 confirmed") so the runner-label fix from this PR's first commit was correct — the workflow just needs a portable enumeration pattern. Replaced `mapfile -t TARGETS < <(find ...)` with: TARGETS=() while IFS= read -r f; do TARGETS+=("$f"); done < <(find ...) — works on Bash 3.2 (macOS) AND Bash 4+ (Linux runners we might add later). The `< <(...)` process substitution is Bash 3.2+ so the overall shape stays portable. Comment-documents the empirical reason so a future contributor doesn't reintroduce the Bash 4+ idiom without realising the Mac runner exists on this lane. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-22 03:16:59 -07:00
cp-be	e5b5afae59	fix(ci): shellcheck-arm64-pilot runs-on label matches Mac mini's actual registration ... The lint-shellcheck-arm64-pilot.yml workflow was perpetually CANCELLED (task_id=0, runner_id=NULL, no log file) because Gitea couldn't assign any registered runner to `runs-on: [self-hosted, arm64]`. The Mac mini runner registered for this lane ships labels ["self-hosted","macos-self-hosted-arm64","arm64-darwin"] per internal#494's capability-honest-labels directive — there is no plain `arm64` label. Two fix options: 1. Change the workflow's `runs-on` to match the registered labels. 2. Add a plain `arm64` label to the Mac mini's registration. Option 1 (this commit) is the cleaner fix: it's code-reviewable, lives on the repo's commit history, and respects `feedback_pc2_runner_labels_must_stay_narrow` (don't widen runner labels speculatively — selectors should match what's there, not the other way around). Option 2 would silently grow the label surface and make a future runner inadvertently match this workflow. Selector now: `runs-on: [self-hosted, arm64-darwin]` — pinned to the Mac-specific arm64 label so Linux-arm64 runners (when we add them) don't accidentally pick up Mac-only shell scripts. Comment block in the workflow header documents the rationale + the rule that `arm64-darwin` is Mac-specific by design. This workflow is ADDITIVE / NOT in branch_protections required_contexts (per the existing comment at line 8), so this fix is reversible and doesn't gate any merge — but the cancelled noise in the status feed goes away and the lane actually runs on the Mac mini going forward. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-22 00:35:37 -07:00