feat: add minimal AI processing support

[JackLau1222]

No description provided.

In general, the fix is to add an explicit permissions: block that limits the GITHUB_TOKEN to the minimal privileges needed. This can be done at the workflow root (applies to all jobs) or per job. Since all jobs here only need to read repository contents (for actions/checkout) and use artifacts (which don’t require repo write access), the safest minimal starting point is permissions: contents: read at the workflow root. If later any job needs more (for example, to update releases or PRs), its specific job-level permissions can override or extend the root configuration.

The single best fix without altering functionality is to add a top-level permissions: block right after the name: Build (or after on: if preferred), setting contents: read. This ensures all jobs (build-linux, build-linglong, build-macos-arm, etc.) run with a read-only token for repository contents and do not rely on potentially broader repository defaults. No changes are required to any steps or actions, and no imports or extra methods are involved because this is purely a YAML configuration change in .github/workflows/build.yaml.

In general, you fix this by adding a permissions: block that grants only the minimum required scopes to the GITHUB_TOKEN. You can add it at the workflow root (applies to all jobs) or per job. Since all shown jobs only need to read repository content, we can set permissions: contents: read at the top level of the workflow. This directly addresses CodeQL’s recommendation and avoids changing job behavior.

Concretely, edit .github/workflows/build.yaml near the top: after the name: Build line (or equivalently at the same indentation level as on: and jobs:), insert a permissions: section:

permissions:
  contents: read

No imports or additional definitions are required. This change does not alter any build steps or actions, it only constrains the automatically provided GITHUB_TOKEN permissions for all jobs including build-linglong.

---

To fix the problem, we should explicitly specify minimal GITHUB_TOKEN permissions either at the workflow level (applying to all jobs) or at the job level for build-macos-arm. Since the analyzer flagged the build-macos-arm job and we only see a subset of the workflow, the least invasive, guaranteed-safe fix within the shown snippet is to add a permissions: block to that job. The job only needs to read repository contents (for actions/checkout) and upload artifacts (which is covered by the token’s default actions scope and does not require repository write permissions), so contents: read is an appropriate minimal setting.

Concretely, in .github/workflows/build.yaml, within the build-macos-arm job definition starting at line 241, add a permissions: section directly under the job name and before runs-on. This will ensure that the token for this job is limited to read-only access to repository contents while preserving existing behavior. No additional imports, methods, or external packages are needed.

In general, the fix is to add an explicit permissions: block either at the workflow root (for defaults) and/or at individual jobs, limiting the GITHUB_TOKEN to the minimal scopes required. Build-only jobs that just check out code, download dependencies, and upload artifacts usually need only contents: read (and, if needed by third-party actions, possibly id-token: write or others), while a release job that publishes a GitHub Release requires contents: write.

For this workflow, the safest minimal change without altering behavior is:

• Add a root-level permissions: block after name: Build that sets contents: read as the default for all jobs.
• Override this default in the upload-release job, adding a job-level permissions: block that grants contents: write (needed for softprops/action-gh-release@v1 to upload release assets).
• We do not need any changes to the build-windows-x64 job body or other build jobs; they will inherit the root contents: read, which is sufficient for actions/checkout, actions/upload-artifact, and actions/download-artifact.

No imports or additional methods are required because this is a YAML workflow configuration change only. All edits must be within .github/workflows/build.yaml, so we will confine the changes there.

In general, fixing this class of problem means adding an explicit permissions: block either at the top level of the workflow (applies to all jobs that don’t override it) or on individual jobs, granting only the scopes actually required. For this workflow, most jobs only need to read repository contents (for checkout) and upload artifacts (which uses the token but via the contents/actions scopes as needed), while the upload-release job additionally needs permission to write release assets (contents: write is sufficient for softprops/action-gh-release).

The best, minimal-impact fix here is to add a workflow-level permissions: block near the top (right under name: Build or under on:) that sets contents: read by default, and then override it in the upload-release job to allow contents: write. This keeps existing functionality while tightening privileges elsewhere. Concretely:

• In .github/workflows/build.yaml, after the on: trigger block and before jobs:, add:

  permissions:
    contents: read

• In the same file, inside the upload-release: job definition, add:

    permissions:
      contents: write

  directly under the needs:/runs-on: block (ordering among job keys is flexible in YAML, but we’ll place it right after runs-on: for clarity). No imports or additional methods are needed, as this is pure workflow configuration.

[sonarqubecloud]

Quality Gate failed

Failed conditions
3 Security Hotspots

See analysis details on SonarQube Cloud