Infra test

[alepefe]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
esa-client	Ready	Preview	Comment	Nov 18, 2025 8:35am

To fix the issue, we should add the explicit permissions key to the root of the workflow file (.github/workflows/deploy-aws.yml). This will set minimal default permissions for all jobs in the workflow, unless overridden per job. According to the CodeQL recommendation, permissions: {} is the most minimal starting point, which disables all access to the GITHUB_TOKEN for API operations. To prevent interruption of basic operations, and since most workflows need at least contents: read access for actions/checkout and possibly other minor actions, we can start with permissions: contents: read. If further write permissions are required by specific steps (for example, deploy or opening pull requests), those jobs should individually override the root permissions block. The change should be added right after the workflow name: and before on:.

The best fix is to explicitly add a permissions: block that sets the minimum required permissions for the workflow. The recommended starting point is contents: read, which is sufficient for most workflows that only need to check out code. If a job or step requires additional permissions (e.g., creating deployments, writing to issues, or other repository operations), those should be added with the narrowest possible scope. As CodeQL highlighted trigger_build job but the workflow as a whole lacks permissions:, we should add it at the root level (just below name: and before on:), so all jobs will inherit these permissions unless overridden individually.

No additional YAML imports or definitions are needed: this is a policy/configuration change.

---

To fix the problem, we should add an explicit permissions key near the top of the workflow file (at the root level, just after name: and on:), setting the least privilege needed by all jobs in the workflow. As a minimal and safe default, we should set permissions: { contents: read }, which allows the workflow to read repository contents but not write or perform other sensitive operations. If jobs in the workflow do need higher privileges (for example, to interact with pull requests, deployments, or issues), we should add only those specific permissions for those jobs at the job level.

Since the CodeQL fix proposal suggests { contents: read } as a safe starting point and no jobs in the text obviously require additional permissions (such as writing to pull requests), we should add this at the workflow root, right after the name and on keys.

Specific changes:

• In .github/workflows/deploy-aws.yml, add the following near the top (after name: Deploy to AWS and after/in between on:):

  permissions:
    contents: read

• Ensure proper YAML indentation.

To fix the issue, explicitly set a permissions block in the workflow file. The ideal approach is placing the block at the root, which will apply to all jobs, unless a job has its own specific block. Since the workflow performs actions like source checkout and docker pushes using AWS credentials (not GITHUB_TOKEN), the minimal required permission is typically contents: read. If jobs require greater permissions (e.g., creating PRs), those should be set only for those jobs. For this fix, we'll follow least privilege and add:

permissions:
  contents: read

at the top level, immediately after the name: field (and before on:). This ensures all jobs use the restricted permissions unless overridden.

---

To fix this error, add an explicit permissions key to the workflow, either at the root level or per job. The best approach is to add a root-level permissions block, which applies to all jobs that do not define their own. Since the workflow only runs jobs that interact with external services and not with repository contents, issues, or pull requests on GitHub, setting the contents: read permission is sufficient and the most restrictive reasonable option. The change should be inserted after the workflow's name and before the on block (typically at the top of the file, before job definitions). No additional imports or code changes are required.