Feature/metrics dashboard

[matthewdeaves]

No description provided.

In general, the fix is to add an explicit permissions block that scopes down the GITHUB_TOKEN to only what the workflow needs. In this workflow, all shown jobs (security, metrics-coverage, metrics-static-analysis, metrics-security, metrics-duplication, etc.) only need to read repository contents (for actions/checkout) and upload artifacts, which does not require any special write scopes to the repository. Therefore, the best minimal fix is to add a single root-level permissions block with contents: read, which applies to all jobs that do not override it.

Concretely, in .github/workflows/ci.yml, insert:

permissions:
  contents: read

near the top of the file, after the name: CI line and before the on: trigger block. This will ensure that every job, including the one beginning at line 167, runs with a read-only GITHUB_TOKEN for repository contents. No additional imports or methods are required; this is purely a YAML workflow configuration change and does not alter the functional behavior of the jobs, since none of them currently rely on write permissions.

In general, the fix is to explicitly define a minimal permissions: block so the GITHUB_TOKEN has only the scopes required. For this workflow, all shown jobs are CI/metrics jobs that only need to read the repository (via actions/checkout) and upload artifacts; they do not need to write to repository contents, issues, or pull requests. Therefore, setting permissions: contents: read at the top level of the workflow is sufficient and avoids repeating the same block in each job.

The single best change with minimal functional impact is to add a root-level permissions: section just under the name: CI line (and before on:). This will apply to all jobs in the workflow, including metrics-security, metrics-static-analysis, metrics-complexity, and metrics-duplication, unless any job overrides it with its own permissions: block. No other code or steps need to change, and no new imports or actions are required.

Concretely:

• Edit .github/workflows/ci.yml.
• Insert:

permissions:
  contents: read

immediately after the existing name: CI line at the top of the file. This ensures CodeQL sees an explicit permission limitation and that the GITHUB_TOKEN is restricted to read-only contents access for the entire workflow.

In general, fix this by explicitly declaring minimal GITHUB_TOKEN permissions either at the workflow root (affecting all jobs without their own permissions) or at the specific job level. For these metrics jobs, they only need to read the repository contents and upload artifacts, which does not require any extra GitHub write scopes, so contents: read is sufficient.

The single best, non-invasive fix is to add a permissions block at the top level of .github/workflows/ci.yml, just under the name: CI line and before on:, setting contents: read. This will apply to all jobs (including metrics-complexity) that do not override it, tightening GITHUB_TOKEN while preserving existing functionality. No additional imports or dependencies are needed; we are only changing workflow configuration.

Concretely:

• Edit .github/workflows/ci.yml.
• After line 1: name: CI, insert:

  permissions:
    contents: read

• Leave all job definitions and steps unchanged.

In general, the fix is to explicitly specify minimal GITHUB_TOKEN permissions for the workflow or for the specific job. Since the metrics jobs only need to read the repository contents and upload artifacts, the minimal safe permission is contents: read. This prevents the job from inheriting potentially broader repo/org defaults.

The best targeted fix here is to add a permissions block to the metrics-duplication job (the one CodeQL flags at line 262). That job uses actions/checkout, actions/setup-node, runs npx jscpd, and uploads artifacts; none of these require write access to the repo. We can therefore insert:

permissions:
  contents: read

directly under the job name (e.g., after metrics-duplication: and before runs-on:). This change is localized to the shown snippet, does not alter functionality, and satisfies the least-privilege recommendation. No imports or additional methods are necessary because this is pure workflow-configuration.