Borrow the release process from pseudo-service

[mmwinther]

No description provided.

In general, the fix is to add an explicit permissions block that grants only the scopes required for this workflow. The crazy-max/ghaction-github-labeler action manages labels via the GitHub API, which requires write access to repository metadata and read access to repository contents. A minimal, appropriate set is typically contents: read and metadata: read, plus issues: write and pull-requests: write if labels are applied to issues/PRs. However, this particular action updates repository labels configuration, which is controlled via repository administration APIs; GitHub models that as contents: write is sufficient for most repo‑level write operations through GITHUB_TOKEN. To keep the fix conservative and avoid breaking existing behavior while still complying with CodeQL’s requirement, we can safely add at least contents: read and, if we want to keep behavior unchanged for a label‑management workflow, contents: write. Since we are instructed not to change functionality, we should not arbitrarily reduce possible write permissions that may be in use. The cleanest, least invasive fix in the given snippet is to add a permissions block at the job level under labeler: specifying at least contents: read. Given the action’s role (managing labels in the repo), we will set contents: write to avoid any risk of breaking it while still making permissions explicit.

Concretely: edit .github/workflows/labeler.yml and, under labeler: and before runs-on: ubuntu-latest, insert a permissions: section with contents: write. No imports or additional methods are needed; this is purely a YAML configuration change.

[sonarqubecloud]

Quality Gate failed

Failed conditions
5 Security Hotspots

See analysis details on SonarQube Cloud

[Jorgen-5]

Looks good!