Commit Graph

8 Commits

Author SHA1 Message Date
APF Portal Bot 202ad5f721 chore(deps): update actions/setup-node action to v6
CI / commits (pull_request) Has been skipped
CI / perf (pull_request) Has been skipped
CI / check (pull_request) Successful in 1m34s
CI / a11y (pull_request) Successful in 2m48s
CI / scan (pull_request) Failing after 3m35s
2026-05-05 14:28:40 +00:00
julien f9ed3cf82a chore(ci): skip perf and commits gates on Renovate-authored PRs (#23)
CI / commits (push) Has been skipped
CI / check (push) Successful in 2m20s
CI / scan (push) Failing after 2m34s
CI / a11y (push) Successful in 1m7s
CI / perf (push) Successful in 3m43s
## Summary
Renovate's dep-bump PRs run the full pipeline today (`check`, `scan`, `commits`, `perf`, `a11y`). Two of those gates have near-zero signal on a typical bump and dominate the wall-clock cost:

- **`perf`** — Lighthouse build + 3-iteration median across the critical-routes list. 3-5 min per PR for a metric that is essentially zero on a patch/minor dep bump (the SPA today serves the static placeholder; even with real routes a typical bump stays inside the median noise floor).
- **`commits`** — re-validates commit messages that Renovate generates from a Conventional-Commits-conformant template. Tautological.

Skip both when the PR author is the `apf-portal-bot` Gitea user. The `push` event on `main` still runs the full pipeline post-merge, so any regression caught by `perf` is detected seconds after merge — fast enough to revert.

Net result: Renovate PRs run `check + scan + a11y` only, ≈ 4-5 min faster per PR.

## ADR amendment

ADR-0017 is amended in the same change:
- "Where Lighthouse CI runs" table now distinguishes human PR / bot PR / push to main / scheduled / local.
- New "Pre-merge gating policy: human PRs vs bot PRs" subsection records the rationale and the human-takeover edge case.
- §Confirmation entry for `perf` is reworded to reflect the conditional gate.

## Test plan
- [ ] After merge, the next Renovate-triggered PR (auto-rebase or new bump) shows only `check`, `scan`, `a11y` queued — no `perf`, no `commits`.
- [ ] A human-opened PR (e.g. this one) still queues all 5 gates.
- [ ] On `push` to `main` post-merge, the full pipeline runs including `perf`.

---------

Co-authored-by: Julien Gautier <julien.gautier@apf.asso.fr>
Reviewed-on: #23
2026-05-05 16:12:19 +02:00
julien f58cf13e33 fix(ci): give Renovate a git identity and a github.com token (#13)
CI / check (push) Successful in 2m24s
CI / commits (push) Has been skipped
CI / scan (push) Failing after 1m8s
CI / a11y (push) Successful in 1m32s
CI / perf (push) Successful in 2m52s
## Summary
First successful Renovate run (after the docker-image fix in #12) extracted 116 deps cleanly but every branch update failed with `fatal: empty ident name not allowed`, then the whole repo aborted on `Lock file error - aborting`. Two root causes:

- **No git identity** — the bot user had an email but no **Full Name** on its Gitea profile, so Renovate produced incomplete git authorship.
- **No github.com auth** — Renovate could not look up versions of GitHub-hosted Actions (`actions/checkout`, etc.) or `containerbase/node-prebuild` (the Node binary it dynamically fetches for lockfile maintenance) — anonymous rate limit (60 req/h) hit.

Fixes:

1. **`renovate.json`** — pin `gitAuthor` explicitly. The Full Name was also set on the bot's Gitea profile for UI consistency, but the override in config means we don't depend on out-of-band UI state.
2. **`.gitea/workflows/renovate.yml`** — pass `RENOVATE_GITHUB_COM_TOKEN` from the new `GITHUBCOM_TOKEN` repo secret (no underscore between GITHUB and COM — Gitea reserves the `GITHUB_*` namespace).
3. **`docs/development.md`** — onboarding procedure now covers both tokens + the Full Name step.

## Manual setup required after merge
Already done in this iteration:
- Bot's Full Name set in Gitea ("APF Portal Bot").
- `GITHUBCOM_TOKEN` repo secret created with a zero-scope github.com PAT.

(If the PAT was leaked during setup, regenerate before merging — the workflow only references the secret name, not the value.)

## Test plan
- [ ] After merge, trigger Renovate manually (Actions → Renovate → Run workflow).
- [ ] No `empty ident name` warning in the logs.
- [ ] No `Lock file error - aborting`; repo finishes with `INFO: Repository finished … "cloned": true`.
- [ ] Renovate creates the dependency dashboard issue + the first batch of grouped PRs (Angular, Nx, NestJS, Prisma, …) signed by `apf-portal-bot`.

---------

Co-authored-by: Julien Gautier <julien.gautier@apf.asso.fr>
Reviewed-on: #13
2026-05-05 13:47:30 +02:00
julien 399a14e0f4 fix(ci): run Renovate via official Docker image (#12)
CI / commits (push) Has been skipped
CI / scan (push) Failing after 2m59s
CI / check (push) Successful in 3m12s
CI / a11y (push) Successful in 48s
CI / perf (push) Successful in 3m56s
## Summary
First Renovate run failed with `reference not found` on `renovatebot/github-action@v40` — act_runner's go-git clone couldn't resolve the major-rolling tag (whether the upstream tag is missing or it's a go-git tag-fetch quirk doesn't really matter — the wrapper action is the wrong layer to fight).

Switch to invoking the official `renovate/renovate:40` Docker image directly. The job container already has the host Docker socket mounted (per `ci-runners.compose.yml`), so the sibling `docker run` works out of the box. Renovate clones the target repo itself via API + token, so no `actions/checkout` or bind-mount is needed.

Net result:
- Decoupled from third-party action-tag resolution.
- Renovate runtime version explicitly pinned (reproducible).
- One fewer indirection to debug.

## Test plan
- [ ] After merge, trigger the workflow manually (Actions → Renovate → Run workflow).
- [ ] Job pulls `renovate/renovate:40` (~1 GB, one-time on this runner host) and runs without "reference not found".
- [ ] Renovate creates the onboarding PR ("Configure Renovate") visible in the repo's PR list, signed by `apf-portal-bot`.

---------

Co-authored-by: Julien Gautier <julien.gautier@apf.asso.fr>
Reviewed-on: #12
2026-05-05 11:42:03 +02:00
julien 82911f9319 chore(ci): set up Renovate dependency automation (#11)
CI / commits (push) Has been skipped
CI / check (push) Successful in 1m21s
CI / scan (push) Failing after 1m27s
CI / a11y (push) Successful in 44s
CI / perf (push) Successful in 2m28s
## Summary
Wire up Renovate to keep dependencies fresh without manual triage.

- **Workflow** — `.gitea/workflows/renovate.yml`: cron daily at 03:00 UTC + `workflow_dispatch`, runs on the existing self-hosted runners. Picked 03:00 specifically so Monday's tick sits inside Renovate's default `lockFileMaintenance.schedule` ("before 4am Monday") and triggers the weekly lockfile refresh in passing.
- **Config** — `renovate.json`: `config:recommended` baseline + groupings (Angular, Nx, NestJS, Prisma, Vitest, TypeScript tooling, ESLint, SWC, Tailwind), Conventional-Commits commit messages, OSV.dev as vulnerability source, dependency dashboard issue.
- **Docs** — new §5 in `docs/development.md` covering the bot onboarding (manual, one-shot), how to trigger Renovate manually, how to review its PRs. The placeholder roadmap entry is dropped from §8.

No ADR — Renovate is operational tooling, not an architectural decision (and on Gitea it's the only viable bot anyway, no real alternative to capture).

## Manual setup required after merge

The workflow is wired but inert until the bot is onboarded once on Gitea:

1. Create a non-admin Gitea user `apf-portal-bot`.
2. Add the bot as a **Write** collaborator on this repo.
3. Sign in as the bot, generate a PAT (scopes: read/write `repository`, read/write `issue`, read `user`).
4. Add the PAT as the repo secret `RENOVATE_TOKEN` (Settings → Actions → Secrets).

Detailed steps in [`docs/development.md`](docs/development.md) → "Dependency updates (Renovate)".

## Test plan
- [ ] After bot onboarding, trigger the workflow manually (Repo → Actions → Renovate → Run workflow).
- [ ] First run creates the "Renovate Dependency Dashboard" issue and a batch of grouped PRs (Angular, Nx, …).
- [ ] Each generated PR has CI green (`check`, `scan`, `commits`, `perf`, `a11y`).
- [ ] Commit subject matches `chore(deps): …` / `fix(deps): …` so the `commits` gate doesn't reject.

---------

Co-authored-by: Julien Gautier <julien.gautier@apf.asso.fr>
Reviewed-on: #11
2026-05-04 17:37:13 +02:00
julien f2440fbf24 fix(ci): disable broken pnpm cache on actions/setup-node (#8)
CI / a11y (push) Successful in 45s
CI / perf (push) Successful in 2m40s
CI / commits (push) Failing after 12m17s
CI / scan (push) Failing after 12m18s
CI / check (push) Failing after 12m19s
## Summary
`act_runner`'s built-in GitHub-Actions-cache server binds inside the runner container on the compose-defined `apf-portal-act-runners` bridge. Jobs spawned via the mounted Docker socket land on Docker's default `bridge` network and can't reach it. Every job opting into `cache: 'pnpm'` ate ~2 min `ETIMEDOUT` on restore + another ~2 min on save — across the 5 jobs, ~20 min wasted per CI run for zero cache hits.

Drop `cache: 'pnpm'` everywhere. `pnpm install --frozen-lockfile` is fast on the warm store inside the job container, so removing the cache layer is a net gain today.

The proper fix (cross-container networking / fixed-port cache binding) is documented in `infra/README.md` → "Cache server (deferred)" so it can be picked up as an isolated infra spike later.

## Test plan
- [ ] CI run on this PR: every job's `Set up Node.js` step finishes in seconds (no ETIMEDOUT warning).
- [ ] `Complete job` step also finishes promptly (no `reserveCache failed` warning).
- [ ] Total wall-clock time for the run should drop by ~15-20 min vs. previous runs.

---------

Co-authored-by: Julien Gautier <julien.gautier@apf.asso.fr>
Reviewed-on: #8
2026-05-04 15:33:04 +02:00
julien b7adf2e308 fix(ci): post-runner-image cleanup (#7)
CI / commits (push) Has been skipped
CI / scan (push) Failing after 6m19s
CI / check (push) Successful in 11m43s
CI / perf (push) Successful in 12m0s
CI / a11y (push) Successful in 10m8s
## Summary
Three follow-up fixes uncovered by the first end-to-end CI run on the self-hosted act_runner image (smoke-test PR).

- **`check` job** — replace `nrwl/nx-set-shas@v4` (GitHub-API only, 404 on Gitea) with a manual shell step that derives `NX_BASE`/`NX_HEAD` from local git history (merge-base on `pull_request`, `HEAD~1` on `push`).
- **`perf` job** — pin to `catthehacker/ubuntu:full-22.04` so Lighthouse CI finds a real Chrome. The default act image (`act-22.04`) is the minimal variant, ships without browsers.
- **`package.json`** — declare `pnpm.onlyBuiltDependencies` to silence the "Ignored build scripts" warning and approve only the post-install hooks we actually rely on (Nx, Prisma, esbuild, swc, native watchers/resolvers).

No ADR change — these are purely operational adjustments.

## Test plan
- [ ] CI run on this PR: `check` and `perf` jobs both green.
- [ ] No "Ignored build scripts" warning in `pnpm install` step output.
- [ ] After merge, `push` event on `main` re-runs `check`, `scan`, `perf`, `a11y` cleanly (no `nx-set-shas` 404).

---------

Co-authored-by: Julien Gautier <julien.gautier@apf.asso.fr>
Reviewed-on: #7
2026-05-04 14:55:14 +02:00
Julien Gautier be7187d5f2 chore: scaffold Gitea Actions pipelines per ADR-0015 / ADR-0017
CI / commits (push) Has been skipped
CI / check (push) Failing after 36s
CI / a11y (push) Failing after 2s
CI / perf (push) Failing after 38s
CI / scan (push) Failing after 2m15s
Wire the CI/CD pipeline scaffolding. Implements the level-2 (Gitea
Actions) part of ADR-0015 with the thin-YAML pattern, plus the perf
gate from ADR-0017. The level-1 decisions (gates list, branch model,
secrets policy) are unchanged.

Files:
- .nvmrc pins Node 24 (latest LTS major) for actions/setup-node.
- package.json gains four ci:* scripts that the workflows call:
  - ci:check  - 'nx affected -t format:check lint test build'
  - ci:audit  - 'pnpm audit --audit-level=moderate'
  - ci:commits- 'commitlint --from $COMMIT_LINT_FROM --to HEAD'
  - ci:perf   - 'nx build portal-shell --configuration=production
                 && lhci autorun --config=./lighthouserc.js'
  All four runnable locally; CI workflows are thin wrappers.
- @lhci/cli added as a dev dependency for ci:perf.
- lighthouserc.js encodes the Core Web Vitals thresholds from
  ADR-0017 (LCP <= 2500ms, CLS <= 0.1, TBT <= 200ms, server
  response <= 800ms, Performance >= 0.9). v1 measures only the
  static-served portal-shell bundle (Nx Welcome placeholder); the
  critical-routes list expands as real screens land.
- .gitea/workflows/ci.yml runs five jobs on PR + push to main:
  check, scan (audit + Trivy + gitleaks), commits (PR-only), perf,
  a11y. The a11y job is a placeholder that no-ops with a clear
  message; it wires up for real with the first Playwright e2e suite
  (ADR-0016). All gates are blocking - branch protection on main
  will require all five jobs green.
- .gitea/workflows/security-scheduled.yml runs weekly (Mon 04:00
  UTC) for full-tree Trivy + gitleaks (no severity filter, no
  skip-dirs - broader than per-PR) plus a Lighthouse run against
  the prod URL when vars.LHCI_PROD_URL is set.

Slight deviation from ADR-0015 §'Level 2': Trivy and gitleaks are
binaries (Go) and don't have clean npm wrappers, so they are
invoked through their official Gitea-Actions-compatible actions
inside the YAML rather than via 'pnpm ci:scan'. The high-level
decision (gates: audit + secret-scan + dep-scan) is unchanged; the
script/action boundary is shifted by one tool. Documented here for
traceability; no ADR amendment needed.

Operational TODOs (not blocking the scaffold):
- pnpm audit currently reports 6 moderate transitive vulnerabilities
  (ajv, brace-expansion, yaml, @hono/node-server, follow-redirects,
  uuid) in deep deps of Nx/Angular plugins. CI will fail on this
  gate until upstream updates land or Renovate bumps; expected and
  documented.
- act_runner self-hosted instances are not yet registered against
  the Gitea organisation; the workflows reference [self-hosted,
  on-prem] runner labels per ADR-0015. CI will not actually execute
  until the runners are up - that's an infra task.
- Branch protection rules on main (require all five jobs green) are
  configured in Gitea UI, not in this commit.
- Lighthouse-prod scheduled job runs only when vars.LHCI_PROD_URL
  is set - skipped silently otherwise. To be configured once a prod
  environment exists.
2026-04-30 19:48:20 +02:00