`git push --mirror` pushes everything under refs/* including refs/pull/*,
which GitHub rejects with "deny updating a hidden ref" — GitHub manages
its own refs/pull/N/head namespace and won't let outside pushers touch it.
Switching to `--all --prune --force` + `--tags --prune --force` scopes the
push to refs/heads/* and refs/tags/* only (same as the original lines)
while keeping --prune so branch/tag deletions still propagate.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Today's cleanup surfaced 14 branches that existed on GitHub but had
been deleted on Gitea — the previous `--all --force` + `--tags --force`
pair pushes refs but never deletes missing ones, so the mirror drifted
over time.
Switching to `git push --mirror` (equivalent to --all --tags --prune
--force) makes the GitHub side a true reflection of Gitea: branch and
tag deletes propagate automatically.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
POST /api/v1/ai-sessions and friends call _require_ai_enabled(), which
returns 503 when no provider key is set. The new prefill-handoff
regression test (e2e/assistant-chat-prefill.spec.ts) drives the
dashboard prefill flow, which has to create a chat session before its
page.route stub on /chat can fire — so without a key, session
creation 503s and the test never sees the task lane.
The Playwright stub intercepts /chat in the browser, so the backend
never actually contacts Anthropic — but the AI-enabled gate still
needs to pass. A stub value is enough.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Before: e2e \`needs: [frontend]\` waited for the frontend job to upload
a build artifact, then downloaded it. With multiple runners this means
the third runner sat idle for ~6 min while frontend ran, then started
e2e — total wall-clock max(backend, frontend+e2e) ≈ 11 min.
After: e2e builds its own frontend (npm ci + npm run build are already
in the job; just dropped the artifact download step and added the
build). e2e starts immediately on a free runner. Adds ~1-2 min to the
e2e job duration but removes ~5 min of waiting and eliminates the
cross-job artifact mechanism entirely.
Side benefit: no more \`actions/upload-artifact\` v3/v4 GHES headaches
on the cross-job handoff. The \`if: always()\` upload of the
playwright-report at the end of e2e is kept (failure report retrieval
is still useful), but it's a leaf-output, not a dependency.
Net wall-clock: max(backend=9m, frontend=6m, e2e=7m) ≈ 9 min on the
3-runner setup, down from ~11 min.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Backend suite is the slow gate (1076 passed locally in 22m27s on
fix/ci-workflow-config). Adding pytest-xdist with per-worker DB
isolation drops it to ~4m20s on the 8-core homelab runner. Verified
locally: `pytest -n auto --no-cov` finished in 4m28s real time
(15m19s user — confirms ~5× parallelism).
How it works:
- conftest.py reads `PYTEST_XDIST_WORKER` (set per worker by xdist —
'gw0', 'gw1', …). When set, derives a per-worker DB URL like
`…/resolutionflow_test_gw0`. The base DB stays for serial / master
runs.
- `_ensure_worker_db_exists` runs synchronously at conftest import,
connects to the postgres maintenance DB, and `CREATE DATABASE`s the
worker-suffixed DB if it doesn't exist. Idempotent across runs.
- The "test" safety guard still applies — every worker DB name
contains "test" so the assertion holds.
- The per-test `DROP SCHEMA public CASCADE` now operates on the
worker's isolated DB, no cross-worker race.
CI workflow: backend job switches to `pytest -n auto`. Coverage still
collected (pytest-cov has built-in xdist support).
Adds `pytest-xdist==3.6.1` to requirements-dev.txt.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
With 3 Gitea Actions runners on the same homelab box, two simultaneous
backend (or backend + e2e) jobs both try to bind 0.0.0.0:5432 for their
postgres service containers. The second fails with:
failed to set up container networking: ... Bind for 0.0.0.0:5432
failed: port is already allocated
The host-port mapping isn't actually needed — the workflow uses
\`DATABASE_URL: postgresql+asyncpg://...@postgres:5432/...\` (hostname
\`postgres\` is the service container's docker-network DNS name).
The tests run inside the act container which is on the same docker
network, so they reach postgres without going through the host.
Removing \`ports: 5432:5432\` from both backend and e2e job service
definitions lets multiple postgres services run in parallel on
different docker networks without colliding on the host.
Surfaced when PR #150 ran in parallel with another job after the
multi-runner setup. Backend instant-failed in 2s on the docker run.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Three changes that get PR #150 to a green CI gate:
1. **test_record_decision_persists_and_bumps_state_version** — the
`decision: draft_template` path calls `_extract_template_parameters`
(TemplateExtractionService → AI provider). CI doesn't set
ANTHROPIC_API_KEY/GOOGLE_AI_API_KEY, so the endpoint raised
`RuntimeError: No AI provider configured` and returned 500. The test
isn't exercising the AI integration — patched the extractor with an
AsyncMock returning a minimal valid `{templated_body, parameters}`
dict. Verified locally: the test now passes.
2. **pip + npm caches** in backend, frontend, and e2e jobs. Keyed on
the hash of requirements*.txt / package-lock.json with a runner-os
restore-key fallback. Saves ~30-60s per run on cache hit.
3. **Pytest invocation tightened**:
- Dropped `--cov-report=term-missing` — the custom "Display coverage
summary" step below parses coverage.json and prints the same
module list more concisely. Term-missing dumps every uncovered
line which adds ~5-10s of stdout.
- Added `--maxfail=10` so a structural breakage (fixture explosion,
DB unreachable) bails after 10 errors instead of running the full
25-min suite. Tunable.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Two CI-config issues blocking the gate from going green:
1. **Backend tests connect to localhost instead of postgres service.**
conftest.py reads DATABASE_TEST_URL only — DATABASE_URL is intentionally
not consulted (per dab740d's test-DB-isolation hardening — running
pytest with DATABASE_URL set previously dropped the dev DB schema).
The CI workflow only sets DATABASE_URL, so conftest falls back to its
localhost default and every fixture-setup fails with
`OSError: Connect call failed ('127.0.0.1', 5432)` — observed as 638
errors on the latest main run.
Add DATABASE_TEST_URL pointing at the postgres service container.
Same connection string as DATABASE_URL — the test DB and the app DB
are the same physical postgres in CI; conftest's safety assertion is
satisfied by the URL containing "test".
2. **Frontend artifact upload fails on Gitea Actions runner.**
actions/upload-artifact@v4 (and v5) are not supported on Gitea
Actions / GHES — the runner returns
`GHESNotSupportedError: ... not currently supported on GHES`. Lint
itself is now passing (0 errors after PR #149); the job exits 1 only
because the upload step then fails.
Pin upload-artifact + download-artifact to v3, the latest version
compatible with Gitea Actions until they ship v4 support.
After this lands, both backend and frontend CI gates should turn
green — at which point we can also add backend to the required status
checks on main.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
