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