Levandor

vuer_oss CI — "Github CI - Branch" audit gate is chronically RED (not a regression)

5 min read

CI gotcha — a red "Github CI - Branch" on a facekom customization branch is almost always the pre-existing audit gate, NOT your change

The “Github CI - Branch” workflow (.github/workflows/audit.yaml in vuer_oss) is chronically RED on customization branches. The failing step is yarn run improved-yarn-audit --min-severity critical --exclude <GHSAs> (audit.yaml:33), which exits non-zero (exit 4) whenever a critical advisory exists in a transitive dependency that is not in the --exclude triage list. Do not mistake it for a regression you introduced.

Verified 2026-06-04 against the live repo and gh run list history.

Why it’s always red

improved-yarn-audit exits 4 if any critical advisory survives the --exclude allowlist. The base branch customization/raiffeisen has failed this same gate on every push since at least April 2026 — the team merges through it. As of 2026-06-04 it trips on 4 stale-dependency advisories:

Dependency pathAdvisory
twig → locutusGHSA-vh9h-29pq-r5m8
@techteamer/timestamp → … → basic-ftpGHSA-5rq4-664w-9x2c
@kafkajs/confluent-schema-registry → protobufjsGHSA-xq3m-2v4x-88gg
request → form-dataGHSA-fjxv-7rqg-78g4

These live in transitive deps; the only ways the team clears the gate are to append the triaged GHSA(s) to the --exclude list in audit.yaml (a security-acceptance decision) or to remediate the dependency.

How to tell it’s the gate vs. your change

Two-question check before assuming a regression

  1. Did your commit touch package.json / yarn.lock? If no, the audit result is unchanged by you.
  2. Is the base branch (e.g. customization/raiffeisen) already red on the same gate? If yes (it is), your branch inherits that red.

Both pointing away from your change ⇒ it’s the pre-existing audit gate. Move on.

The gates that actually matter per-change

A red audit gate is noise; these are the real signals:

  • Lint — yarn lint (eslint --max-warnings 0; ignores customization/test/*). Zero-tolerance on warnings.
  • Unit tests — yarn jest <file>.

Treat lint and the relevant Jest runs as the gates that gate your change.

SonarCloud “Security Rating on New Code” can fail on new CI workflow lines

CI gotcha — adding lines to a SonarCloud-scanned GitHub Actions workflow can fail the "Security Rating on New Code" quality gate

SonarCloud scans .github/workflows/* with GitHub-Actions supply-chain rules. Adding new lines to a workflow in a PR can trip the “Security Rating on New Code” gate — even when the rest of the CI already uses the same patterns. The existing jobs are grandfathered as old code; only the PR’s new lines are evaluated against the new-code gate.

First hit on FKITDEV-8239 (the depcheck-CI rollout): 4 of 5 PRs failed this gate after adding a depcheck job.

What gets flagged (GHA supply-chain rules)

ConstructRule rationale
npx <tool>”can install packages on-demand…” (on-demand install). Confirmed sole driver on vuer_css.
yarn install / npm install”lifecycle scripts…” (install can run arbitrary lifecycle scripts)
actions/foo@v6 (a tag/branch ref)“Use full commit SHA” (pin actions to a full commit SHA, not a floating tag)

Quality profiles differ per repo

The flagged set is not uniform — it depends on each project’s SonarCloud quality profile. On FKITDEV-8239: vuer_css flagged only npx; portal_css flagged all three. Don’t assume one repo’s findings carry to another.

Resolutions

  1. Exclude .github/** from analysis (used on FKITDEV-8239) — append .github/** to sonar.exclusions in sonar-project.properties. TechTeamer repos already list .github/** under sonar.coverage.exclusions, so this just extends the existing exclusion to the analysis scope. Lowest-friction fix.
  2. Make the new lines compliant — run CLI tools via a pinned devDependency (e.g. yarn depcheck) instead of npx, and pin every action to a full commit SHA. More invasive but keeps .github/** under Sonar’s eye.

Reading the per-PR findings without a SonarCloud token

The SonarCloud issue/rule REST APIs require auth for these private projects (no anonymous read). But the per-PR findings are still readable through GitHub alone: SonarCloud posts each issue as a GitHub check-run annotation on the PR head commit —

gh api repos/<org>/<repo>/check-runs/<check-run-id>/annotations

Full recipe (find the “SonarCloud Code Analysis” check + head SHA → check-run id → annotations) is documented at Reading SonarCloud PR issues WITHOUT a Sonar token (gh check-run annotations).

  • vuer_oss — the service whose CI this concerns.
  • FKITDEV-8827 — Raiffeisen PION face-comparison export task; surfaced on a customization/raiffeisen-based branch where this gate reads red regardless of the change.
  • customization-branches — the per-client customization branches that all inherit this red audit gate.
  • release-process — CI/CD overview (audit.yaml listed under GitHub Actions).
  • security-audit — FaceKom vulnerability findings (separate from this CI-gate triage).
  • FKITDEV-8239 — depcheck-CI rollout; first hit of the SonarCloud “Security Rating on New Code” GHA supply-chain gate, fixed via .github/** in sonar.exclusions.
  • FKITDEV-8887 — full tokenless SonarCloud check-run-annotation read recipe + the “passing gate ≠ zero issues” gotcha.
  • cve-2025-7783-form-data-via-request — deep-dive on the request → form-data GHSA-fjxv-7rqg-78g4 row in the table above: the resolutions fix pattern, and the Unable to parse yarn audit output / DEP0169 lines are cosmetic debugging trap (they appear on green runs too).
  • customization-branch-ci-pipeline-inheritance — why partner branches that never ran an audit job suddenly start failing it after their first devel-merge.

Graph View

Backlinks