Files
apf_portal/.gitea/workflows/ci.yml
T
julien e389567a3c
CI / commits (push) Has been skipped
CI / check (push) Successful in 5m33s
CI / scan (push) Successful in 6m39s
CI / a11y (push) Successful in 4m16s
CI / perf (push) Successful in 7m25s
Docs site / build (push) Successful in 3m29s
fix(ci): move grpc-tools to optionalDependencies (revert NODE_OPTIONS attempt) (#200)
## Summary

The `NODE_OPTIONS=--use-system-ca` workaround merged in #199 did not clear the CI install failure — the runner still rejects the TLS chain to `node-precompiled-binaries.grpc.io`. Either the runner's OS CA bundle is missing the same intermediate Node's bundled set is missing, or `--use-system-ca` does not propagate down to the `node-fetch@2` that `node-pre-gyp` uses. Without runner shell access the exact reason is not worth chasing.

Switch angle: **the protoc binary `grpc-tools` downloads is never used in CI**. The generated TypeScript stubs in `apps/portal-bff/src/grpc/gen/` are committed per [ADR-0024](docs/decisions/0024-ai-service-relay-grpc-sse-bridge.md) §"Sub-decision 3 — vendored protos", so CI only needs to type-check them; protoc only runs when a developer regenerates from `apps/portal-bff/src/grpc/proto/apf-ai/*.proto`.

This PR moves `grpc-tools` from `devDependencies` to `optionalDependencies`. Per pnpm semantics, when an optional dep's install (including postinstall) fails, pnpm logs a warning and the overall install completes. CI's `pnpm install --frozen-lockfile` therefore succeeds even when the binary cannot be fetched; developer machines (where TLS validates) install grpc-tools normally and `pnpm grpc:codegen` works unchanged.

## What lands

- `package.json` — `grpc-tools: "^1.13.0"` moves out of `devDependencies` and into a new `optionalDependencies` block. The entry in `pnpm.onlyBuiltDependencies` stays — it controls whether pnpm *attempts* the postinstall, not whether failure is fatal. Local installs (where TLS works) still run the postinstall and download the binary.
- `pnpm-lock.yaml` — refreshed; the lockfile reflects the new optional-dep classification. No version changes to anything else.
- `.gitea/workflows/ci.yml` — revert the workflow-level `env: NODE_OPTIONS: --use-system-ca` block added in #199. Did not help; left in place it would be a misleading "this is supposed to fix CI TLS" signpost.
- `.gitea/workflows/docs-site.yml` — same revert.

## Notes for the reviewer

- **Why `optionalDependencies` is the right primitive.** pnpm 10 documents the contract: a package listed in `optionalDependencies` is *attempted*; if the install fails for any reason (platform mismatch, postinstall script error, network failure), the failure is logged and the overall command continues. That maps exactly to what this PR needs: try in CI, fail gracefully, succeed locally.
- **Why not remove `grpc-tools` from `pnpm.onlyBuiltDependencies` instead.** Removing it from the allowlist tells pnpm not to even *try* the postinstall, which would also fix CI. But it would also break the developer workflow — locally, the protoc binary would never download, and `pnpm grpc:codegen` would fail. The dev would have to manually trigger the build (`pnpm approve-builds` then `pnpm rebuild grpc-tools`), or worse, devs would commit accidental `package.json` mutations from `approve-builds`. The `optionalDependencies` route keeps the local DX identical.
- **Why revert the workflow `env:` blocks.** They do not help here, and leaving them in place implies that `--use-system-ca` is the canonical fix for this class of failure — which it is *not*, at least not for this runner / this CDN. If a future native dep hits a similar wall and `--use-system-ca` *does* fix it for that case, the env var lands in a focused PR with a real validation. Carrying it now as a "maybe useful later" workaround is noise.
- **Codegen workflow on developer machines.** Unchanged. `pnpm install` runs the postinstall (TLS validates locally), the protoc binary lands in `node_modules/`, `pnpm grpc:codegen` regenerates stubs. The only visible difference is a one-line `WARN GET_RESOLVED_FROM_REGISTRY ...` if a contributor ever encounters the same TLS failure locally (e.g., on a corporate-proxied machine) — pnpm will mark grpc-tools as failed-optional and the rest of the install proceeds; the dev can then debug their own network without blocking the whole repo.
- **Idempotence with CI's `--frozen-lockfile`.** The lockfile change is small (re-classifies grpc-tools from `dev` to `optional`) and lands in this PR. After merge, CI runs against the new lockfile; no further coordination needed.

## Test plan

- [x] `pnpm install` locally — clean, grpc-tools postinstall runs successfully (TLS validates), protoc binary present.
- [x] `pnpm grpc:codegen` — regenerates the TypeScript stubs identically (no diff in `apps/portal-bff/src/grpc/gen/`).
- [x] `pnpm nx run-many -t lint test build -p portal-shell,portal-admin,portal-bff,shared-ui,shared-charts` — all five projects green.
- [ ] **CI green on this PR's first run.** The validation that matters: `pnpm install --frozen-lockfile` completes despite grpc-tools' postinstall failure; `ci:check` runs to completion.
- [ ] Spot-check of post-merge CI runs over the next few days to confirm the warning is recurring (expected) and the install never fails (the contract).

## What's next

- If the CI behaviour is what this PR predicts (warning instead of failure), no further action required.
- If `optionalDependencies` does not work as documented (highly unlikely, but possible if the pnpm version has a regression), the fallback is to drop `grpc-tools` from `pnpm.onlyBuiltDependencies` and add a small dev-onboarding note. One-line change away.
- Long-term cleanup: if a future PR migrates the codegen step to a Docker-based tool (`buf`, system protoc) the optional-dep entry can be removed entirely. Out of scope here.

---------

Co-authored-by: Julien Gautier <julien.gautier@apf.asso.fr>
Reviewed-on: #200
2026-05-20 15:06:25 +02:00

215 lines
9.2 KiB
YAML

# Per ADR-0015 (CI/CD on Gitea Actions).
# Thin YAML — orchestration lives in package.json scripts (ci:check,
# ci:audit, ci:commits, ci:perf) and Nx targets. Any change to gate
# behaviour belongs in those scripts, not in this file.
name: CI
on:
pull_request:
branches: [main]
push:
branches: [main]
jobs:
check:
runs-on: [self-hosted, on-prem]
steps:
- uses: actions/checkout@v6
with:
fetch-depth: 0
# Derive NX_BASE / NX_HEAD for `nx affected`. Replaces
# nrwl/nx-set-shas@v4, which is GitHub-only (it queries the GitHub
# API to find the last successful workflow run, returning 404 on
# Gitea). HEAD~1 is a reasonable approximation for push events on
# a squash-merge trunk; pull_request uses the merge-base with the
# target branch.
- name: Derive Nx affected base and head
shell: bash
run: |
# `actions/checkout@v4` with fetch-depth: 0 already pulls every
# branch and tag, so origin/<base_ref> is present locally — no
# extra `git fetch` is needed (and `--depth=0` is invalid: git
# requires a positive integer).
if [ "${{ github.event_name }}" = "pull_request" ]; then
echo "NX_BASE=$(git merge-base HEAD origin/${{ github.base_ref }})" >> "$GITHUB_ENV"
else
echo "NX_BASE=HEAD~1" >> "$GITHUB_ENV"
fi
echo "NX_HEAD=HEAD" >> "$GITHUB_ENV"
- uses: pnpm/action-setup@v6
- uses: actions/setup-node@v6
with:
node-version-file: '.nvmrc'
cache: 'pnpm'
- run: pnpm install --frozen-lockfile
- run: pnpm ci:check
scan:
runs-on: [self-hosted, on-prem]
# Step ordering matters here: Trivy and gitleaks BOTH run before
# `pnpm install`. Reason: gitleaks scans the working tree
# (`--no-git --source .`), and after install, `node_modules/`
# and `.pnpm-store/` are full of upstream packages whose READMEs
# and test fixtures contain demo RSA keys / fake API tokens —
# gitleaks then false-positives on them by the hundreds (caught
# the hard way: 381 hits on the first run). Trivy reads
# `pnpm-lock.yaml` for its vuln scan, not `node_modules`, so it
# also doesn't need install. `pnpm ci:audit` does the same — it
# queries the advisory DB against the lockfile.
steps:
- uses: actions/checkout@v6
- uses: pnpm/action-setup@v6
- uses: actions/setup-node@v6
with:
node-version-file: '.nvmrc'
cache: 'pnpm'
# Dependency vulnerability scan. Trivy is a Go binary, not an npm
# package, so it cannot live in package.json scripts as cleanly
# as audit/lint do.
#
# We deliberately avoid `aquasecurity/trivy-action`. On cache
# miss the action falls back to `git clone github.com/aquasecurity/
# trivy` to fetch its install script, using `actions/checkout`
# which defaults `with.token` to `${{ github.token }}` (Gitea's
# auto-token, useless for github.com). The clone hits the
# anonymous github.com rate limit and fails with "could not
# read Username". Passing GITHUB_TOKEN as an env var doesn't
# help — actions/checkout reads it from `inputs.token`, not env.
#
# Direct curl + tar is simpler, predictable, and gives us an
# explicit version pin instead of `@master`. GITHUBCOM_TOKEN is
# passed to handle the github.com rate limit on the release
# download in the worst case (release artefacts are usually
# unmetered, but auth is free insurance).
- name: Install Trivy
env:
# renovate: datasource=github-releases depName=aquasecurity/trivy
TRIVY_VERSION: '0.70.0'
GITHUB_TOKEN: ${{ secrets.GITHUBCOM_TOKEN }}
run: |
curl -sfL \
-H "Authorization: Bearer ${GITHUB_TOKEN}" \
-o /tmp/trivy.tar.gz \
"https://github.com/aquasecurity/trivy/releases/download/v${TRIVY_VERSION}/trivy_${TRIVY_VERSION}_Linux-64bit.tar.gz"
tar -xzf /tmp/trivy.tar.gz -C /usr/local/bin trivy
trivy --version
- name: Run Trivy
# `--scanners vuln`: limit Trivy to vulnerability scanning. Its
# secret scanner false-positives on demo RSA keys embedded in
# the README/fixtures of cryptographic npm packages (which
# land under .pnpm-store/), and we already have gitleaks below
# as the dedicated secret-scan gate. Trivy's intent in this
# job, per ADR-0015, was always "dependency vulnerability
# scan" — restoring that scope.
run: |
trivy fs \
--scanners vuln \
--ignore-unfixed \
--skip-dirs node_modules \
--exit-code 1 \
--severity CRITICAL,HIGH \
.
# Secret scan. Same install pattern as Trivy: gitleaks is a Go
# binary, and the official `gitleaks/gitleaks-action@v2` wrapper
# is now paywalled for organisations (a GITLEAKS_LICENSE secret
# from gitleaks.io is required, otherwise the action errors out
# with `🛑 missing gitleaks license`). The binary itself stays
# MIT-licensed and free — installing it directly bypasses the
# wrapper and gives us version pinning for free.
- name: Install gitleaks
env:
# renovate: datasource=github-releases depName=gitleaks/gitleaks
GITLEAKS_VERSION: '8.30.1'
GITHUB_TOKEN: ${{ secrets.GITHUBCOM_TOKEN }}
run: |
curl -sfL \
-H "Authorization: Bearer ${GITHUB_TOKEN}" \
-o /tmp/gitleaks.tar.gz \
"https://github.com/gitleaks/gitleaks/releases/download/v${GITLEAKS_VERSION}/gitleaks_${GITLEAKS_VERSION}_linux_x64.tar.gz"
tar -xzf /tmp/gitleaks.tar.gz -C /usr/local/bin gitleaks
gitleaks version
- name: Run gitleaks
# `--no-git --source .` scans the working tree only. The scan
# job uses a shallow checkout, so a git-history scan would not
# see beyond HEAD anyway; the weekly security-scheduled
# workflow does the deep history scan with a full clone.
# `--redact` masks any matched secret in the log output so we
# do not leak it via the CI logs themselves.
run: |
gitleaks detect \
--no-git \
--source . \
--redact \
--exit-code 1
# npm-advisory check (against pnpm-lock.yaml). Run last so
# `pnpm install` does not pollute the working tree before the
# scanners above.
- run: pnpm install --frozen-lockfile
- run: pnpm ci:audit
commits:
# PRs opened by Renovate (apf-portal-bot) carry commit messages
# generated from a vetted Conventional-Commits template — running
# commitlint on them is tautological. Per ADR-0017 amendment.
if: github.event_name == 'pull_request' && github.event.pull_request.user.login != 'apf-portal-bot'
runs-on: [self-hosted, on-prem]
steps:
- uses: actions/checkout@v6
with:
fetch-depth: 0
- uses: pnpm/action-setup@v6
- uses: actions/setup-node@v6
with:
node-version-file: '.nvmrc'
cache: 'pnpm'
- run: pnpm install --frozen-lockfile
- run: COMMIT_LINT_FROM=origin/main pnpm ci:commits
perf:
# Skip the Lighthouse run on PRs opened by Renovate (apf-portal-bot):
# the per-PR perf signal on a dep bump is essentially zero (no
# routes yet, bundle is the static placeholder), and the Lighthouse
# round-trip burns several minutes per PR. Push events on `main`
# still run perf — we catch regressions immediately post-merge,
# not pre-merge. Per ADR-0017 amendment.
if: github.event_name != 'pull_request' || github.event.pull_request.user.login != 'apf-portal-bot'
runs-on: [self-hosted, on-prem]
# Lighthouse CI drives a real Chrome instance; the default act runner
# image (catthehacker/ubuntu:act-22.04) ships without one. The :full
# variant adds Chrome, Firefox, and the GUI-test toolchain — pinned
# to the same Ubuntu 22.04 base as the default labels for parity.
container:
image: catthehacker/ubuntu:full-22.04
steps:
- uses: actions/checkout@v6
- uses: pnpm/action-setup@v6
- uses: actions/setup-node@v6
with:
node-version-file: '.nvmrc'
cache: 'pnpm'
- run: pnpm install --frozen-lockfile
- run: pnpm ci:perf
- uses: actions/upload-artifact@v7
if: always()
with:
name: lighthouseci-report
path: .lighthouseci/
retention-days: 30
a11y:
runs-on: [self-hosted, on-prem]
steps:
- uses: actions/checkout@v6
- uses: pnpm/action-setup@v6
- uses: actions/setup-node@v6
with:
node-version-file: '.nvmrc'
cache: 'pnpm'
- run: pnpm install --frozen-lockfile
# Placeholder until the e2e a11y suite (axe-core via Playwright,
# per ADR-0016) is wired with the first real screens. The job
# exists so branch protection can require it from day one - it
# currently no-ops with a clear message.
- run: echo "a11y gate placeholder - axe-core via Playwright wires up with the first real screens (ADR-0016)."