ci: v0.13.0 — DNS diagnostics daemon-side probe uses local node:22-alpine (no image pull)

This commit is contained in:
2026-09-19 07:53:22 +00:00
parent 54c7a0c5f5
commit c30f5f650f
2 changed files with 3 additions and 2 deletions
+2 -1
View File
@@ -44,7 +44,8 @@ jobs:
done done
curl -so /dev/null --max-time 10 -w 'registry.npmjs.org https %{time_total}s\n' https://registry.npmjs.org || echo 'curl registry FAILED' curl -so /dev/null --max-time 10 -w 'registry.npmjs.org https %{time_total}s\n' https://registry.npmjs.org || echo 'curl registry FAILED'
echo '=== daemon-side (default bridge) ===' echo '=== daemon-side (default bridge) ==='
timeout 90 docker run --rm alpine sh -c 'cat /etc/resolv.conf; nslookup registry.npmjs.org >/dev/null 2>&1 && echo "daemon-bridge DNS OK" || echo "daemon-bridge DNS FAILED"' || echo 'daemon-side probe FAILED' # node:22-alpine is already local on the shared daemon (CI builds use it) — no pull needed when the network is down.
timeout 90 docker run --rm node:22-alpine sh -c "cat /etc/resolv.conf; node -e \"require('dns').lookup('registry.npmjs.org',(e,a)=>{console.log(e?'daemon-bridge DNS FAILED':'daemon-bridge DNS OK '+a);process.exit(e?1:0)})\"" || echo 'daemon-side probe FAILED'
- name: Setup Node - name: Setup Node
uses: actions/setup-node@v4 uses: actions/setup-node@v4
+1 -1
View File
@@ -9,7 +9,7 @@
- **@playwright/test pinned as devDependency** (`1.63.0`, matching the shared remote browser server image and the global install) so CI is self-contained; still excluded from the runtime image via .dockerignore (comment updated), prod-deps stage unaffected - **@playwright/test pinned as devDependency** (`1.63.0`, matching the shared remote browser server image and the global install) so CI is self-contained; still excluded from the runtime image via .dockerignore (comment updated), prod-deps stage unaffected
- `AGENTS.md`: "Change process" + "E2E tests" rewritten for the PR workflow — feature branch off master → commits with CHANGELOG entry + version bump → PR to master → CI (build→unit→e2e) green → merge → tag on master → manual production deploy via `docker compose up -d --build`; no direct pushes to master, CI never deploys - `AGENTS.md`: "Change process" + "E2E tests" rewritten for the PR workflow — feature branch off master → commits with CHANGELOG entry + version bump → PR to master → CI (build→unit→e2e) green → merge → tag on master → manual production deploy via `docker compose up -d --build`; no direct pushes to master, CI never deploys
- **CI build reliability + caching** (after first dind runs): the e2e image is now built with `--progress=plain` before `up -d` so BuildKit step output lands in job logs instead of being hidden by auto progress; Dockerfile bun installs use a BuildKit cache mount (`/root/.bun/install/cache`) that persists on the runner's shared daemon, and CI restores/saves node_modules + the bun cache via actions/cache around dependency install (both steps `continue-on-error` — safe while the runner's cache server is being fixed) - **CI build reliability + caching** (after first dind runs): the e2e image is now built with `--progress=plain` before `up -d` so BuildKit step output lands in job logs instead of being hidden by auto progress; Dockerfile bun installs use a BuildKit cache mount (`/root/.bun/install/cache`) that persists on the runner's shared daemon, and CI restores/saves node_modules + the bun cache via actions/cache around dependency install (both steps `continue-on-error` — safe while the runner's cache server is being fixed)
- **CI DNS diagnostics, retries removed** (transient EAI_AGAIN failures seen in runs #10/#11): retry wrappers around bun/dep install and the e2e image build were dropped — the flaky runner DNS is a config problem to be fixed on the runner side, not papered over; instead a non-fatal "DNS diagnostics" step logs job-container vs daemon-side resolver config plus per-host lookups (registry.npmjs.org, cdn.playwright.dev, github.com, docker.io) so the next flaky run shows exactly which layer is broken - **CI DNS diagnostics, retries removed** (transient EAI_AGAIN failures seen in runs #10/#11): retry wrappers around bun/dep install and the e2e image build were dropped — the flaky runner DNS is a config problem to be fixed on the runner side, not papered over; instead a non-fatal "DNS diagnostics" step logs job-container vs daemon-side resolver config plus per-host lookups (registry.npmjs.org, cdn.playwright.dev, github.com, docker.io); the daemon-side probe runs in a throwaway node:22-alpine container — image already local on the shared daemon, no pull needed when the network is down — so the next flaky run shows exactly which layer is broken
- Verified: unit suite 234 green locally; e2e not run locally by design (would deploy to production) — first real pass happens in the PR's CI run - Verified: unit suite 234 green locally; e2e not run locally by design (would deploy to production) — first real pass happens in the PR's CI run
## v0.12.2 — 2026-09-18 14:06 ## v0.12.2 — 2026-09-18 14:06