Repository navigation
ci(sonar): run one scan against bcgov_common-notify, with coverage - #263
Open
NikhilMM89 wants to merge 2 commits into
Open
NikhilMM89 wants to merge 2 commits into
NikhilMM89 wants to merge 2 commits into
Conversation
Two problems, neither of which the missing token alone explains. action-test-and-analyse guards its scan with `if: inputs.sonar_token`, and its own input description says "provide unpopulated token for pre-setup (will skip)". SONAR_TOKEN_BACKEND and SONAR_TOKEN_FRONTEND are not set on this repo, so the scan has been skipped on every run while the Analysis workflow reported success. Verified in run 37652147135: the scan action is downloaded, SONAR_TOKEN is empty on every line, no scanner output is produced, and all four jobs pass. A pipeline that looks like it is analysing and is not is worse than one that is visibly absent, so each job now emits a GitHub warning annotation when its token is empty. A warning rather than a failure, so PRs stay green until the token lands. The project keys were still the template's - quickstart-openshift_backend and quickstart-openshift_frontend - so even with a valid token the scan would have reported into a project this repo does not own, or failed on access. Changed to bcgov_common-notify_backend / _frontend, matching the repo's current name (it was renamed from nr-notify; the git remote still carries the old one) and the bcgov_ prefix convention visible on existing org projects. No SonarCloud project exists for this repo yet - searching the bcgov-sonarcloud organisation for "common-notify" returns nothing - so the remaining work is a bcgov/devops-requests issue asking for a monorepo project with backend and frontend components, then adding the two tokens as repo secrets. The keys above are what that request should ask for so config and reality match. Checked while in here: both vitest configs emit the lcov reporter to the default ./coverage, which is what sonar.javascript.lcov.reportPaths expects, and CI produces it - the backend job runs 133 test files green with coverage enabled. So nothing else blocks the scan once the token exists.
…eated The earlier commit assumed a monorepo and configured two project keys, bcgov_common-notify_backend and _frontend. SonarCloud provisioned ONE project instead - bcgov_common-notify - and bcgov_common-notify_backend returns 404. Left as it was, the scan would have failed with "project not found" the moment a token was added. Two scanners cannot push to a single project key and have the results merge; whichever finishes last replaces the other's. So the scan happens once, over both apps, which is also the shape bcgov documents for a monorepo in one project (sonar.sources=ppr-api/src,ppr-ui/src in bcgov/sonarqube). The two test jobs keep running lint, tests and coverage, and now publish their lcov as artifacts; a new sonar job collects both and scans once. The suites still run exactly once - coverage is handed over, not regenerated. Secret is now a single SONAR_TOKEN rather than the per-component pair, matching the standalone convention in the quickstart README. `triggers:` is removed from both test jobs, which is a real behaviour change: every PR now runs both suites. With one Sonar project the scan needs coverage from both apps on every run, otherwise a backend-only PR would report the frontend as uncovered and the project's coverage would flap. The suites take about a minute each. The skip is still visible. The scan is guarded on the token, so without one the job would pass having analysed nothing - how this went unnoticed to begin with. It warns instead, and stays green until the token is added. Already confirmed live: the project exists (bcgov_common-notify, analysed 2026-10-08, 99,652 ncloc, 44 vulnerabilities, 22 bugs, 722 smells) but reports NO coverage, because automatic analysis cannot run tests. This replaces that with CI-based analysis so coverage is imported.
NikhilMM89
changed the title
|
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why SonarQube isn't running
Two problems. The missing token was only one of them.
1. The scan has been silently skipped on every run.
bcgov/action-test-and-analyseguards its scan withif: inputs.sonar_token, and its own input description says "provide unpopulated token for pre-setup (will skip)". No token was set, so the scan never ran — while Analysis reported ✅ success.Verified in run 37652147135: the scan action is downloaded,
SONAR_TOKEN:is empty on every line, no scanner output is produced, and all four jobs pass.The scan is still guarded on the token, so it now emits a warning annotation instead of passing in silence. A warning, not a failure — PRs stay green until the token is added.
2. The project keys were wrong, twice.
They started as the quickstart template's (
quickstart-openshift_backend). I first changed them tobcgov_common-notify_backend/_frontend, assuming the monorepo setup we requested.SonarCloud provisioned one project instead:
So the two-key config would have failed with "project not found" the moment a token was added.
One scan, not two
Two scanners cannot push to a single project key and have results merge — whichever finishes last replaces the other's. So the scan now happens once over both apps, which is also the shape bcgov documents for a monorepo in one project (
sonar.sources=ppr-api/src,ppr-ui/srcin bcgov/sonarqube).backend-testsandfrontend-testskeep running lint, tests and coverage, and now publish theirlcov.infoas artifactssonarjob collects both and scans onceSONAR_TOKEN, matching the standalone convention in the quickstart READMEBehaviour change worth noting
triggers:is removed from both test jobs, so every PR now runs both suites.With one Sonar project the scan needs coverage from both apps on every run. Otherwise a backend-only PR would report the frontend as uncovered and the project's coverage percentage would flap run to run. Each suite takes about a minute.
What's left
Add the token as a repo secret:
Generate it from https://sonarcloud.io/account/security. The warning annotation disappears on its own once it exists — no follow-up change.
Current state in SonarCloud
The project is live and already analysed, via Automatic Analysis:
Coverage is absent because automatic analysis can't run tests. This PR replaces that with CI-based analysis so the existing lcov pipeline is actually imported — both vitest configs already emit
lcovto./coverage, and CI produces it (the backend job runs 133 test files green with coverage enabled).Thanks for the PR!
Deployments, as required, will be available below:
Please create PRs in draft mode. Mark as ready to enable:
After merge, new images are deployed in: