The GRO-1983 fast restoration swapped Corepack's pnpm shim for a real
`npm install -g pnpm@9.15.4` binary, which is the right move. But the
GRO-1997 evidence gate still showed the first `reset-demo-data` pod
(...-nh7vg) hitting `getaddrinfo EAI_AGAIN registry.npmjs.org` before a
retry succeeded — the cache was writable, the cold-cache registry
download wasn't eliminated. This is the durable fix:
1. `ENV COREPACK_ENABLE_DOWNLOAD_FALLBACK=0` in `base` and `runner`:
defence in depth so a Corepack shim can never silently re-download
pnpm, even if it is somehow re-introduced.
2. `ENV HOME=/tmp` in the `migrate`, `seed`, and `reset` stages:
under `readOnlyRootFilesystem: true` + `runAsUser: 1000`, the
default HOME path is read-only, and pnpm fails the first time it
tries to write a config or state file. The job pods already mount a
writable emptyDir at `/tmp`; point HOME there.
3. CI smoke tests for `seed` and `reset` images (matching the existing
`migrate` smoke): point `registry.npmjs.org` at 127.0.0.1 in a
throwaway container, assert `which pnpm` resolves to
`/usr/local/bin/pnpm` (real binary, not shim), and that `pnpm
--version` succeeds without network egress. If Corepack ever sneaks
back in, CI catches it on every PR.
The vestigial `RUN mkdir -p /home/node/.cache/node/corepack` in the
`builder` stage (mentioned in the spec) was already removed in GRO-1909
(commit 0a3eb8a), so nothing to do there.
Follow-on cleanup of the per-job `COREPACK_HOME` env vars and
`node-cache` emptyDir mounts in `groombook/infra` is intentionally
deferred to a coordinated infra PR once the new image is deployed —
keeping the existing infra in place during the transition avoids a
flag-day.
GRO-1985, hardening follow-up to GRO-1984 / GRO-1983.
Closes parent: GRO-1981.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
- Fix API image tag typo: groombok -> groombook (line 103)
- Fix Reset image cache-from/cache-to indentation: moved from under tags: (12 spaces) to under with: (10 spaces)
- This corrects the Reset image build failure in CI runs.
fix(GRO-1576): add provenance: false to all build-push-action steps (#64)
Disables OCI attestation manifest generation that was hitting a Gitea registry bug when image layers are pre-existing.
Reviewed-by: Lint Roller (QA)
Approved-by: The Dogfather (CTO)
Docker Buildx v6 defaults to OCI attestation manifests (--attest
type=provenance,mode=max). These hit a Gitea registry bug when image
layers are pre-existing (blob mount), causing "unknown" errors on manifest
list push. API image succeeds because it pushes new layers; migrate/seed/
reset fail because their layers already exist.
Disabling provenance attestation on all four build-push-action steps
resolves the push failures. Addresses GRO-1575.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
The root pnpm scripts typecheck/lint/test the stale src/ directory.
Use pnpm --filter @groombook/api to target the correct apps/api/ path,
matching the GitHub Actions CI configuration.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Flea Flicker
Flea Flicker
Lint Roller
The Dogfather
Chris Farhood