fix(ci): Restore CI workflow permission compatibility

[tintinhamans]

This restores GenCI after #3276 broke the replay workflow by requesting pull-requests: write, while the caller did not grant it.

Reusable workflows now inherit permissions from explicit caller declarations. Their filenames start with reusable-, and the required permissions are documented in the workflow header.

Historical builds only get write permissions when creating a release.

---

Tested on my fork, result looks good: https://github.com/tintinhamans/GeneralsGameCode/actions/runs/34748506756

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-13T19:57:26.710325Z	40045cc	Manual request
🔒 Security Review	✅ Completed 2026-09-13T09:29:29.857612Z	40045cc	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Restore caller-owned permissions for reusable CI workflows

🐞 Bug fix ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Move reusable workflow permissions to callers to restore replay checks.
• Prefix reusable workflows with underscores and document required permission scopes.
• Limit historical write access to release creation jobs.

Diagram

graph TD
  CI["GenCI caller"] -->|"Caller permissions"| BUILD(["Build workflow"]) -->|"Executes"| BUILDJOBS(["Build jobs"])
  CI -->|"Contents read"| REPLAY(["Replay workflow"]) -->|"Executes"| REPLAYJOBS(["Replay checks"])
  WEEKLY["Weekly caller"] -->|"Contents read"| BUILD
  HISTORICAL["Historical caller"] -->|"Job-only write"| RELEASE(["Release job"])

Loading

High-Level Assessment

The caller-owned permission model is the best fit for GitHub reusable workflows because permissions cannot be elevated beyond the caller's token scope. Keeping reusable workflows permission-neutral restores compatibility and preserves least privilege; retaining write permissions inside reusable workflows or at workflow-wide scope was appropriately dismissed.

Files changed (5) +18 / -11

Bug fix (2) +9 / -7

_check-replays.ymlRemove incompatible replay workflow permissions +3/-3

Remove incompatible replay workflow permissions

• Removes the reusable workflow's contents and pull-request permission declaration. Documents that callers only need to grant contents-read access for replay checks.

.github/workflows/_check-replays.yml

ci.ymlGrant replay permissions from the GenCI caller +6/-4

Grant replay permissions from the GenCI caller

• Updates build and replay jobs to reference the underscore-prefixed reusable workflows. Explicitly grants contents-read permission to the replay caller, restoring compatibility without pull-request write access.

.github/workflows/ci.yml

Other (3) +9 / -4

_build-toolchain.ymlDocument caller-owned build permissions +4/-1

Document caller-owned build permissions

• Marks the underscore-prefixed build workflow as reusable and documents the caller permissions required for normal builds and vcpkg cache uploads. The reusable workflow intentionally declares no permissions itself.

.github/workflows/_build-toolchain.yml

build-historical.ymlScope historical release write access +3/-1

Scope historical release write access

• Changes the workflow-wide contents permission from write to read. Grants contents-write access only to the conditional release creation job.

.github/workflows/build-historical.yml

weekly-release.ymlReference the renamed reusable build workflow +2/-2

Reference the renamed reusable build workflow

• Updates both weekly build jobs to call the underscore-prefixed toolchain workflow while retaining their explicit contents-read scopes.

.github/workflows/weekly-release.yml

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can start a comment with 'qodo' or '@qodo' to chat about any finding

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[greptile-apps]

Greptile Summary

This PR restores reusable CI workflow compatibility by moving permission declarations to callers and renaming reusable workflow files.

• Grants replay checks only the required read permission.
• Limits historical-build write permission to release creation.
• Updates all local callers to reference the renamed reusable workflows.

Confidence Score: 5/5

The PR appears safe to merge; workflow references and caller-owned permission declarations are internally consistent.

No new actionable issue or outstanding previous finding remains, and all renamed reusable-workflow references resolve to current files.

Important Files Changed

Filename	Overview
.github/workflows/ci.yml	Updates reusable workflow references and explicitly grants read permission to replay checks.
.github/workflows/build-historical.yml	Reduces workflow-wide permissions and scopes contents write access to the release job.
.github/workflows/reusable-build-toolchain.yml	Renames the build workflow and documents that callers must declare required permissions.
.github/workflows/reusable-check-replays.yml	Removes incompatible reusable-workflow permission declarations and documents the caller requirement.
.github/workflows/weekly-release.yml	Updates release build jobs to invoke the renamed reusable build workflow.

_{Reviews (2): Last reviewed commit: "fix(ci): Make reusable workflow permissi..." | Re-trigger Greptile}

[xezon]

I do not understand the leading underscore. Is this a github convention or just made up here?

[tintinhamans]

I do not understand the leading underscore. Is this a github convention or just made up here?

Since we cannot put the reusable workflows in a subfolder, I thought it would be good to differentiate them like this. It's a convention used by some other projects too.

[xezon]

It is unclear how a third party will derive this convention from the file name. Maybe add a named prefix to the files instead that clarifies the goal?

[Copilot]

🔵 Needs a closer look

CI permission and reusable-workflow inheritance behavior cannot be fully validated in this sandbox and warrants a human confirming the live workflow runs, even though the changes appear complete and correct.

Pull request overview

This PR restores CI (GenCI) compatibility after #3276 broke the replay workflow. It formalizes the pattern that reusable workflows do not declare their own permissions and instead inherit them from the calling job. Reusable workflows are renamed with a leading _, their required permissions are documented in header comments, and each caller job now grants exactly the permissions it needs (including a newly added contents: read on the replay-check job that previously caused a startup failure by requesting pull-requests: write it wasn't granted). It also narrows build-historical.yml so contents: write is only granted to the release job.

Changes:

• Renamed reusable workflows to _build-toolchain.yml / _check-replays.yml and updated all uses: references in ci.yml and weekly-release.yml.
• Removed permission declarations from the reusable workflows (replacing them with documentation comments) and added permissions: contents: read to the replaycheck-generalsmd caller job.
• Scoped build-historical.yml to top-level contents: read, granting contents: write only to the create-release job.

File summaries

File	Description
.github/workflows/ci.yml	Points to _-prefixed reusable workflows and adds contents: read to the replay-check job.
.github/workflows/weekly-release.yml	Updates uses: references to the renamed _build-toolchain.yml.
.github/workflows/build-historical.yml	Moves contents: write from workflow level to the create-release job only; top-level becomes contents: read.
.github/workflows/_check-replays.yml	Renamed reusable workflow; removes permissions (incl. pull-requests: write) in favor of caller-declared permissions with a documenting comment.
.github/workflows/_build-toolchain.yml	Renamed reusable workflow; replaces permissions note with a WARNING documenting caller-granted permissions.

Review details

• Files reviewed: 5/5 changed files
• Comments generated: 0
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[tintinhamans]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Bravo.

Reviewed commit: 40045ccdc2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[tintinhamans]

It is unclear how a third party will derive this convention from the file name. Maybe add a named prefix to the files instead that clarifies the goal?

Changed to use reusable- prefix for clarity.