Add linting workflow for multiple languages

[ReginaldWang]

This workflow defines multiple jobs for linting C, CMake, Perl, and configuration files, as well as running CodeQL analysis on pull requests.

Problem and Scope

I may have forgotten some linting tools, and perl linting tools are still incomplete.

Description

Gotchas and Limitations

Testing

• HOOTL testing
• HITL testing
• Human tested

Testing Details

Larger Impact

Additional Context and Ticket

In general, the fix is to define an explicit permissions: block to restrict the GITHUB_TOKEN to the minimum required scope, instead of relying on repository/organization defaults. Since these jobs only check out code and run local linters/echo commands, they only need read access to repository contents.

The best minimal fix here is to add a top-level permissions: block next to on: (at the workflow level). This will apply to all jobs (clang, cmake, perl, configs) and avoids repeating the block per job. We can safely set contents: read, which is sufficient for actions/checkout@v4 to fetch the source. No other scopes (such as pull-requests: write) are needed, because the workflow does not post comments, update statuses directly, or modify issues/PRs. Concretely, in .github/workflows/BundleLinters.yml, insert:

permissions:
  contents: read

between the on: block and the jobs: block.

In general, the fix is to explicitly set the permissions for the GITHUB_TOKEN at the workflow or job level so they follow the principle of least privilege. Since all jobs only check out code and run local commands, they only need read access to repository contents.

The best fix here is to add a workflow‑level permissions block near the top of .github/workflows/BundleLinters.yml, just under the name: and on: keys. This block should set contents: read, which is sufficient for actions/checkout@v4 and does not grant any write permissions. Adding it at the workflow level ensures all jobs (clang, cmake, perl, configs) inherit these minimal permissions without needing per‑job duplication. No additional methods, imports, or definitions are required since this is purely a configuration change in the YAML workflow file.

To fix the problem, explicitly declare restricted GITHUB_TOKEN permissions in the workflow. Since all jobs only check out code and run local commands, they only need read access to repository contents. The best fix is to add a permissions block at the workflow root (same indentation level as on: and jobs:). This will apply to all jobs that don’t have their own permissions block, which matches this file.

Concretely, edit .github/workflows/BundleLinters.yml to insert:

permissions:
  contents: read

between the on: section and the jobs: section. No other changes, imports, or definitions are needed, and existing behavior remains identical except that the GITHUB_TOKEN will be restricted to read-only repository contents.

To fix this, explicitly restrict the GITHUB_TOKEN permissions in the workflow to the minimum required. Since all jobs only check out code and run local commands, they only need read access to repository contents. The cleanest approach is to add a top-level permissions block to the workflow so it applies to all jobs, instead of repeating the same block under each job.

Concretely, in .github/workflows/BundleLinters.yml, insert a top-level permissions: section after the name: Lint (or before on:) with contents: read. This will ensure all jobs (clang, cmake, perl, configs) run with a GITHUB_TOKEN that can only read repository contents and cannot write to code, issues, or pull requests. No additional imports or methods are needed since this is purely a YAML configuration change and does not change the functionality of the existing steps.

[dchansen06]

Updating with rebase