Skip to content

Follow-ups for CodeQL version-bump automation: packages:read permission + issue-body indentation #162

Description

@felickz

Two minor follow-ups identified during Copilot code review on PR #160, deferred to keep that PR moving (not blocking, both non-functional-critical or easy low-risk fixes):

1. update-codeql-version.yml may need packages: read permission

The job's permissions: block only sets contents: read:

permissions:
  contents: read # PR creation uses a scoped GitHub App token (SECLABS_APP_ID/SECLABS_APP_KEY), not GITHUB_TOKEN

but the workflow runs codeql pack upgrade across every pack dir, which resolves codeql/<lang>-all dependencies from GitHub Packages. ci.yml explicitly grants packages: read for the same kind of pack resolution:

permissions:
  contents: read
  packages: read

If codeql pack upgrade needs authenticated package read access here too, this workflow could fail with 403s the first time it's actually run via workflow_dispatch. Add packages: read to update-codeql-version.yml's job permissions to match ci.yml, then verify with a live dispatch run.

(Originally flagged in PR #160 review comment: #160 (comment))

2. detect-codeql-release.yml tracking-issue body renders as a code block

The BODY="..." bash multi-line string (used for gh issue create/gh issue edit) has extra leading whitespace on its continuation lines (beyond the base YAML run: | indentation), added for readability in the workflow source. Bash preserves that literal whitespace in the variable, and GitHub Markdown treats 4+ leading spaces as an indented code block — so the rendered tracking issue body (bullet list + links) may appear as a monospace code block instead of normal formatted Markdown.

Fix by building the body without extra leading whitespace (e.g. via printf or an unindented heredoc-style string), then verify the rendered issue looks right after a real run.

(Originally flagged in PR #160 review comment: #160 (comment))

Why deferred

Both update-codeql-version.yml and detect-codeql-release.yml are brand new in PR #160 and can only be truly exercised via workflow_dispatch/cron after merge to main (workflow_dispatch requires the workflow to exist on the default branch first). Recommend fixing these as part of — or immediately after — the first live test of each workflow post-merge, rather than adding more commits/CI cycles to #160 now.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions