Skip to content

ci(sonarqube): FerrGames, UI, FerrFlow-Cloud and the FerrLabs-Cloud frontends have no static analysis #188

Description

@BryanFRD

Static analysis reaches repos through the reusable CI workflows — reusable-ci-node.yml, reusable-ci-rust.yml and reusable-ci-astro.yml all run Sonar. Repos that don't call one get no analysis at all, and the gaps are in the places that matter most.

Actual coverage

Repo Calls a CI reusable? Analysed
FerrGames-Cloud no — only release/docker/security-scan nothing — gameserver, api, site, app-ng, admin
UI no nothing — the design system every app consumes
FerrFlow-Cloud no nothing — the public marketing site
FerrLabs-Cloud reusable-ci-rust.yml only Rust API yes; admin/, app/, auth/, bff/ no
FerrGrowth / FerrTrack / FerrVault / FerrLens / MCP / Kit / Status yes yes

So the two largest and most sensitive surfaces in the org are the least analysed:

  • FerrGames-Cloud is the biggest repo (~3.5 MB) and contains the WebSocket gameserver — stateful, concurrent, real-time code, which is exactly the category where a scanner earns its keep. It has zero coverage.
  • FerrLabs-Cloud's frontends include auth/ — the login, signup, 2FA and OAuth-authorize UI. The Rust half is analysed; the half users actually type their password into is not.
  • UI is consumed by every product, so a defect there propagates to all of them, and nothing scans it.

Why this is worth doing rather than another manual pass

A point-in-time audit finds what someone thought to look for on the day. A scanner in CI finds regressions on every push, forever, including the classes a human sweep misses by construction. The org already pays for the tooling and already runs it on 14 repos — the gap is enrolment, not capability.

Scope

  • Wire FerrGames-Cloud, UI and FerrFlow-Cloud into the appropriate reusable CI workflow (or add a standalone sonarqube.yml like Infra and Kubernetes use, where the reusable does not fit)
  • Extend FerrLabs-Cloud to also run the Node analysis over admin/, app/, auth/, bff/
  • Agree what happens on new findings: quality gate blocking, or advisory first. Blocking on a codebase that has never been scanned will light up — advisory for one cycle, then gate on new code only, is the usual way in.

Note FerrLabs-Cloud and FerrFleet-Cloud were previously excluded from the reusable-ci-rust.yml rollout because of their git-rev Kit dependencies; that constraint applies to the Rust job, not to adding Node analysis for their frontends.

Not urgent: Fixtures, Changelog, Claude-Agents, Benchmarks are also unanalysed but small and low-stakes. Benchmarks already runs ShellCheck + bats, which is the right tooling for what it is.

Acceptance

  • Every product repo has its whole codebase analysed, not only its backend
  • A new finding on FerrGames-Cloud or auth/ surfaces in CI rather than in an audit

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions