jklein
67d8c94fb3
Validate Helm Charts / Detect changed charts (pull_request) Successful in 4s
Validate Helm Charts / Build ${{ fromJSON(needs.detect-changed-charts.outputs.charts) }} (pull_request) Skipped
Validate Helm Charts / Trivy config ${{ fromJSON(needs.detect-changed-charts.outputs.scan-charts) }} (pull_request) Skipped
Validate Helm Charts / Install-test (pull_request) Skipped
Validate Helm Charts / Resource quantities (pull_request) Successful in 9s
SonarQube Analysis / SonarQube Analysis (push) Failing after 1m0s
Adds the caller side of the analysis: .github/workflows/sonar.yml as a hull of
the same kind as the publish ones, and sonar-project.properties as the
project-specific half. The workflow itself is the shared block in
workflow-util/pipelines, bound to @v4.
No paths filter, unlike the publish hulls: the analysis looks at the whole tree
- the five shell scripts under ci/, every workflow file, the YAML and Helm
templates, the values.schema.json files, and the secret detection over
everything. A filter would leave the previous result standing after a change it
did not cover while still presenting it as current.
workflow_dispatch is on the hull on purpose. Three things about this path are
unmeasured - node24 in the runner image, the ~59 MiB scanner download, and
whether a repository variable reaches a workflow called from another repository
- and any of them may need more than one attempt. Without a dispatch every
attempt would cost a dummy commit on main.
No exclusions, including the Helm templates, which are not valid YAML because
of {{ }}. What the Helm and YAML analysers make of them is only learnable by
letting them run over them once, and an exclusion written on a guess hides
whatever else matches it. If the first run produces noise worth suppressing,
the exclusion belongs in sonar-project.properties with the finding it answers
named next to it.
The project key carries the owner (jlab-cluster_helm-charts) because the
instance serves two, and a key cannot be changed afterwards without losing the
project's history.
The analysis is not a gate. The Community Build analyses the main branch only,
so the trigger is a push to main and a finding appears after the merge - at
which point there is nothing left to block. README and the CI-CD wiki page both
say so, with the two conditions under which a gate would become right, so that
its absence is not read as an oversight.
38 lines
1.9 KiB
YAML
38 lines
1.9 KiB
YAML
name: SonarQube Analysis
|
|
|
|
# The analysis itself lives in workflow-util/pipelines, bound to a tag like
|
|
# every other call to that repository. This hull only decides WHEN it runs.
|
|
#
|
|
# No "paths" filter, unlike the publish-<chart>.yml hulls: the analysis looks at
|
|
# the whole tree - the five shell scripts under ci/, every workflow file, the
|
|
# YAML and Helm templates, the values.schema.json files, and the secret
|
|
# detection that covers everything. A filter would mean a change outside the
|
|
# filter leaves the last result standing while claiming to be current.
|
|
on:
|
|
# push on main, and only main, because the SonarQube Community Build analyses
|
|
# the main branch only - there is no pull-request analysis to hook into. The
|
|
# consequence belongs said out loud rather than discovered: a finding appears
|
|
# AFTER the merge. This is an observation of the state of main, not a gate,
|
|
# and the shared block deliberately carries no quality-gate step.
|
|
push:
|
|
branches:
|
|
- main
|
|
# workflow_dispatch, and it is not decoration. Three things about this path
|
|
# are unmeasured - whether node24 is in the runner image, whether the ~59 MiB
|
|
# scanner download gets through (a 17 MB one once did not, MTU 1500 against a
|
|
# pod network of 1450), and whether a repository variable reaches a workflow
|
|
# called from another repository. Any of them may need more than one attempt,
|
|
# and without a dispatch every attempt would cost a dummy commit on main.
|
|
# Only the maintainer can trigger it; the bot account cannot dispatch.
|
|
workflow_dispatch:
|
|
|
|
jobs:
|
|
sonar:
|
|
name: SonarQube Analysis
|
|
uses: workflow-util/pipelines/.gitea/workflows/sonar-analysis.yml@v4
|
|
# secrets: inherit passes SONAR_TOKEN through. The block declares it as
|
|
# required, and a missing required secret fails job CREATION on this
|
|
# instance, not the job - the run would stand there with no steps at all.
|
|
# SONAR_HOST_URL is a repository variable and needs nothing here.
|
|
secrets: inherit
|