🐛 Fix Invoice Regeneration

[drexhacker]

No description provided.

In general, the fix is to explicitly declare a permissions block that grants the minimum necessary scopes. This can be done at the workflow root (applies to all jobs without their own permissions) and/or at the job level. Here, build-and-push already has a job-level permissions block. The guard, test, and deploy jobs don’t use the GITHUB_TOKEN, so they can run with permissions: contents: read or even permissions: {} (no permissions). Adding a root-level permissions block of contents: read will be a clear, minimal default; we then only need to override it where broader permissions are required (already done for build-and-push).

The single best minimal-change fix is:

• Add a workflow-level permissions block just after the on: section, setting contents: read. This documents and enforces a safe default for guard, test, and deploy.
• Leave the existing permissions block in build-and-push unchanged, since it already correctly requests id-token: write and contents: read.

This addresses CodeQL’s complaint (the job now inherits explicit, minimized permissions) without altering any functional behavior of the jobs.

To fix this, we should explicitly restrict GITHUB_TOKEN permissions instead of relying on repository defaults. The minimal necessary permission for the test job is contents: read, since it only checks out code and runs tests. We can add a permissions block to the test job specifying contents: read. The build-and-push job already has an explicit permissions section, and the guard job doesn’t need more than read access either, but CodeQL flagged specifically the test job, so we will minimally fix that.

Concretely, in .github/workflows/deploy-aws.yml, within the test job definition (lines 32–56), insert:

    permissions:
      contents: read

between the needs: [guard] and defaults: keys. No imports or external dependencies are required; this is purely a YAML configuration change inside the existing workflow.

In general, the fix is to explicitly set a restrictive permissions block either at the workflow root (affecting all jobs) or on each job individually. Since build-and-push already has its own permissions block, the smallest and safest change is to add an explicit permissions block to the deploy job only. This documents the intended permissions and ensures the GITHUB_TOKEN is limited even if repository defaults are broad or change in the future.

For this specific workflow (.github/workflows/deploy-aws.yml), the deploy job does not need to modify repository contents or metadata; it only interacts with AWS using long-lived credentials from secrets. Therefore, we can safely set permissions: contents: read as a minimal, least-privilege setting, which is equivalent to the typical “read-only” default for repository contents. Concretely, you should insert:

    permissions:
      contents: read

just under runs-on: ubuntu-latest (line 123) in the deploy job, before needs: or environment:. No additional imports, actions, or method definitions are required; this is a declarative change in the workflow YAML.