## What this does
Removes the third-party `awalsh128/cache-apt-pkgs-action` from CI
entirely, installing zsh + fish with a plain `sudo apt-get update &&
sudo apt-get install -y zsh fish` at all four call sites:
- `ci.yaml` — `code-coverage`
- `nightly.yaml` — `feature-powerset` and `benchmarks`
- `.github/actions/test-setup/action.yaml` — composite action used by
the required `test` matrix
It also drops the Dependabot `ignore` entry for the action (no longer
needed once the action is gone).
## Why (and why this supersedes #3321)
`awalsh128/cache-apt-pkgs-action@v1.6.2` (dependabot bump #3311) empties
its own `packages: zsh fish` argument in the "Normalizing package list"
step and aborts with `Packages argument is empty`, in ~20s, before any
compilation — killing `code-coverage` on every PR, which in turn stopped
`codecov/patch` from posting anywhere. Root cause is upstream PR #177
quoting `${packages}`, tracked at
[awalsh128/cache-apt-pkgs-action#210](https://github.com/awalsh128/cache-apt-pkgs-action/issues/210).
#3321 already fixed main by pinning back to `v1.6.1`. This PR takes the
sturdier route — dropping the dependency — based on the upstream's
health:
- Issue #210 is open with **no maintainer engagement**; affected users
call the action "basically non-functional," with a fresh repro confirmed
on 2026-06-29.
- **No open PR** reverts #177 or fixes the regression; v1.6.2 (broken)
is still tagged `Latest`, and contributor PRs sit unmerged for months.
- The action's mutable `v1`/`latest` tags are actively being retargeted
upstream (open PR #211), which is how a `@v1.6.1` ref can resolve to
drifted code — so even the pin isn't a stable anchor.
`zsh` and `fish` are in the standard Ubuntu repos (no PPA), so the
action only *cached* an install of two tiny packages — a negligible
speed-up for a third-party dependency that is under-maintained, broke CI
repo-wide, and can't be stably pinned. Dropping it removes the whole
failure class and matches the existing `musl-tools` install already in
`nightly.yaml`. Verified: the identical `apt-get` step already runs
green in the required `test (linux)` job (installs zsh 5.9 + fish
3.7.0), and a full `code-coverage` run on this branch completed green
end-to-end with `codecov/patch` posting again.
## Guard against recurrence
#3311 merged while its own `code-coverage` was red because
`code-coverage`/`codecov/patch` aren't *required* status checks (only
`test (linux/macos/windows)` are), and `codecov/patch` was absent rather
than red (the job died before uploading), so the mechanical-bump merge
saw nothing blocking. Recommended guard: make the `code-coverage` job a
required status check — it fails only on genuine breakage (the codecov
upload already soft-fails on fork PRs), so it blocks this class without
re-introducing the flake that keeps `codecov/patch` itself advisory.
> _This was written by Claude Code on behalf of max_
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
## Problem
CI on `main` fails in the required `code-coverage` job ([failed
run](https://github.com/max-sixty/worktrunk/actions/runs/28358354325)).
The `Install shells (zsh, fish)` step aborts:
```
PACKAGES: zsh fish
Normalizing package list...
Validating action arguments (version='1', packages='')...
exit status 100Packages argument is empty.
##[error]Process completed with exit code 3.
```
This is a deterministic regression in
`awalsh128/cache-apt-pkgs-action@v1.6.2`, introduced by the bump in
#3311. v1.6.2's new "Normalize package list" step turns the input `zsh
fish` into an empty string before validation. Upstream root cause: PR
#177 added quotes around `${packages}` in `get_normalized_package_list`,
so `apt_query` treats the entire space-separated list as one package
name and the normalization yields nothing — tracked at
[awalsh128/cache-apt-pkgs-action#210](https://github.com/awalsh128/cache-apt-pkgs-action/issues/210).
v1.6.2 is still the latest release with no fix.
#3311 bumped three of the four call sites (`ci.yaml` `code-coverage`,
two in `nightly.yaml`); `.github/actions/test-setup/action.yaml` was
never bumped and stayed on v1.6.1 — which is why test-setup-based jobs
passed while `code-coverage` failed.
## Solution
Revert the three v1.6.2 references to v1.6.1, the known-good version the
test-setup action already uses, so all four sites are consistent again.
Also add a Dependabot `ignore` for v1.6.2 of this action so the daily
github-actions update doesn't immediately re-create the same broken
bump; the entry is scoped to that one version, so Dependabot can bump
forward once a fixed release ships.
This is the right level: the failure is entirely upstream, the fix
matches the existing precedent (#2583 pinned this action), and pinning
back is a clean revert rather than a workaround layered on a broken
release.
## Testing
The fix is a CI-config change; correctness is verified by CI itself
re-running the `code-coverage` job with v1.6.1. The v1.6.1 path is
already exercised by every existing run via `test-setup`, which never
failed on this step.
Note: the advisory (non-required) `collect affected coverage (windows)`
leg in the failed run also failed, on an unrelated PTY flake
(`test_switch_picker_create_validates_templates_before_worktree`) — a
separate known-flaky Windows shell-integration test, not caused by this
commit and not addressed here.
---
Automated fix for [failed
run](https://github.com/max-sixty/worktrunk/actions/runs/28358354325)
Co-authored-by: worktrunk-bot <254187624+worktrunk-bot@users.noreply.github.com>
Co-authored-by: Claude <noreply@anthropic.com>
Maximilian Roos