Migrate to gha only

[james-nesbitt]

• switch to GHA for release operations
• clean up any release build information from Make system

To fix the problem, explicitly set a permissions block to scope down the GITHUB_TOKEN for each job, instead of relying on potentially broad repository defaults. The build job only needs to read repository contents and use artifacts, so contents: read is sufficient. The release job needs to create a GitHub Release, which requires contents: write, but does not obviously require other write scopes.

The best minimal fix without changing functionality is:

• Add a permissions block under build: with contents: read.
• Add a permissions block under release: with contents: write.

We do not need to modify steps, environment variables, or add imports; the change is purely in .github/workflows/release.yml. The new permissions entries should be added right under each job definition line (build: and release:) so they apply at the job level. No other files are involved.

In general, fix this by explicitly defining a permissions block that grants the least privileges needed. You can define it at the workflow root (applies to all jobs unless overridden) and, if a specific job needs more privileges, override just for that job.

For this workflow:

• The build job only checks out code, sets up Go, builds binaries, and uploads artifacts. It requires only read access to repository contents and the ability to read artifacts; it does not need any write permissions.
• The release job downloads artifacts and creates a GitHub Release via softprops/action-gh-release, which needs contents: write (to create the release and upload assets). It does not obviously need write access to issues, pull requests, or other scopes.

The best minimal change is:

1. Add a root‑level permissions block with contents: read so both jobs default to read‑only.
2. Add a permissions block under the release job that sets contents: write (overriding the root for that job only).

This leaves existing functionality unchanged (the release can still be created) while explicitly documenting and constraining token capabilities.

Concretely:

• At the top level, after name: Release and before on:, add:

  permissions:
    contents: read

• Under the release job (same indentation level as name: Create GitHub Release and runs-on), add:

    permissions:
      contents: write

No imports or extra methods are needed because this is a YAML workflow configuration change only.

In general, the fix is to explicitly define a permissions: block that limits the GITHUB_TOKEN to the least privileges required. For this workflow, all jobs only need to read repository contents (for actions/checkout) and do not interact with issues, PRs, or other GitHub resources, so contents: read at the workflow level is sufficient.

The best change with no functional impact is to add a top-level permissions: block immediately after the name: and before on: in .github/workflows/pr.yml. This will apply to all jobs in the workflow (since none currently define their own permissions: blocks) and will restrict GITHUB_TOKEN to read-only access to repository contents. No per-job overrides are needed, and no additional imports or changes inside job steps are required.

Concretely:

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

permissions:
  contents: read

between the existing name: PR Validation line and the on: block. No other files or lines need to change.

In general, fix this by adding an explicit permissions block that grants only the scopes needed by the jobs. Since all jobs in this workflow just check out code and run local commands, they only need read access to repository contents. The simplest, least‑privilege approach is to set permissions: contents: read at the workflow root so it applies to all jobs, unless overridden.

The single best fix without changing existing functionality is: in .github/workflows/pr.yml, immediately after the name: PR Validation line (line 4), add a root‑level permissions: block:

name: PR Validation

permissions:
  contents: read

on:
  pull_request:
    branches: [ main ]

This restricts the GITHUB_TOKEN to read‑only repository contents for all jobs (lint, unit-test, integration-test, build-verification, security-scan). No additional imports, methods, or definitions are needed because this is a YAML configuration change only.

In general, the fix is to explicitly define the GITHUB_TOKEN permissions at the workflow or job level, granting only what is needed. Since all jobs in this workflow only perform read operations on the repository (checkout, build, test, security scan) and do not create or modify issues, PRs, releases, etc., they can safely run with contents: read. The simplest and clearest change is to add a root-level permissions block right after name: PR Validation. That way, the minimal permissions apply to all jobs, and we avoid repeating the same block for each job.

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

permissions:
  contents: read

between the name: PR Validation line and the on: block. No additional methods, imports, or other definitions are required; this is purely a YAML configuration change within the workflow.

To fix the problem, explicitly restrict the GITHUB_TOKEN permissions used by this workflow so they follow the principle of least privilege. Since all jobs only need to read the repository contents (to run make commands, tests, builds, and scans) and do not push changes, update PRs, or modify issues, we can set contents: read at the workflow level. This will apply to all jobs in the file unless overridden, and it avoids duplicating the same block for each job.

Concretely, in .github/workflows/pr.yml, add a permissions: block near the top-level (alongside name: and on:). For example, directly after the name: PR Validation line, insert:

permissions:
  contents: read

No other imports, methods, or definitions are required; this is purely a YAML configuration change inside the existing workflow file. This change does not alter the functional behavior of the jobs, because they only require read access to the repository.

In general, the fix is to explicitly declare the minimal GITHUB_TOKEN permissions needed by the workflow, either at the root of the workflow (applying to all jobs) or per job. This workflow only checks out code and runs Go tooling; it does not need to write to the repo or modify issues/PRs. Therefore, the best fix is to add a workflow‑level permissions block that sets contents: read, which is the minimal useful scope for actions/checkout and covers all current jobs without changing their functionality.

Concretely, in .github/workflows/pr.yml, add a permissions: section near the top of the file (for example, right after the name: line) with contents: read. This will apply to all jobs (lint, unit-test, integration-test, build-verification, security-scan) unless overridden later, and satisfies CodeQL’s requirement while enforcing least privilege. No imports, methods, or additional definitions are required for this change.

In general, the fix is to explicitly declare a minimal permissions block for the workflow or each job, limiting GITHUB_TOKEN to the least privilege required. For this workflow, the actions used (actions/checkout, actions/setup-go, go test, actions/upload-artifact) do not need to write to repository contents or pull requests, so contents: read at the workflow level is sufficient. No other fine-grained scopes (like pull-requests: write) are needed based on the shown steps.

The best way to fix this without changing functionality is to add a top-level permissions block right after the name: Build and Test line in .github/workflows/build.yml. This will apply to all jobs that do not override permissions, covering both build and test jobs. The block should be:

permissions:
  contents: read

No imports or additional definitions are needed, since this is just YAML configuration. The only file to modify is .github/workflows/build.yml, and the changes are confined to adding the new lines after the name: line (line 4 in the provided snippet).

In general, fix this by adding a permissions block that grants only the scopes required by the jobs. Since this workflow only checks out code, builds, runs tests, and uploads artifacts (which do not require repository write permissions), it can use read-only repository access.

The best minimal fix without changing behavior is to add a workflow-level permissions block (applies to all jobs) under the name: or on: section, setting contents: read. Neither the build nor test job needs finer-grained or write permissions, and actions/checkout, actions/setup-go, and actions/upload-artifact all work with read-only contents. No additional imports or external dependencies are required; this is purely a YAML configuration change inside .github/workflows/build.yml.

Concretely:

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

permissions:
  contents: read

between the name: Build and Test line and the on: block (or immediately under on:; either is fine, but top-level is clearer). No other changes are necessary.