.github/workflows/docs.yml (2)

10-13: Confirm PATH_TO_DOCS is actually consumed by the reusable workflow.
Reusable workflows don’t automatically inherit arbitrary env from callers. If the called sphinx.yml expects an input (e.g., path_to_docs), pass it via with:, or drop this env if unused.

If the reusable workflow accepts an input for the path, update like:

 jobs:
   docs:
     permissions:
       pages: write
       id-token: write
-    uses: cpp-linter/.github/.github/workflows/sphinx.yml@main
+    uses: cpp-linter/.github/.github/workflows/sphinx.yml@main
+    with:
+      path_to_docs: docs/_build/html  # adjust to the actual input name

To verify the expected interface, I can look up the workflow’s inputs and adapt this PR accordingly—just confirm the repo/branch you want me to check.

---

15-21: Optional: add concurrency to auto-cancel superseded runs.
Saves minutes on rapid pushes to the same branch.

You can add at the workflow top level:

 on:
   push:
     branches: [main]
   pull_request:
     branches: [main]
   workflow_dispatch:
 
+concurrency:
+  group: docs-${{ github.ref }}
+  cancel-in-progress: true

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

.github/workflows/pre-commit.yml (1)

13-14: Per-job contents: read is correct given top-level permissions: {} — optional alignment with your repo-level preference

With permissions: {} at the workflow root, the reusable workflow would have no token scopes unless granted here; adding contents: read at the job is the least-privilege fix. Noting your prior preference to manage contents: read via repository defaults, you could alternatively drop the top-level permissions: {} (and this per-job block) to let repo settings apply. Pick one model to avoid confusion.

Do you want to keep the hardened model (root {} + per-job grants) consistently across workflows, or revert to repo-level defaults for simplicity?

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: 2bndy5
PR: cpp-linter/cpp-linter#150
File: .github/workflows/release.yml:0-0
Timestamp: 2025-09-04T03:33:27.578Z
Learning: In GitHub workflows, `contents: read` permissions can be controlled via repository settings for `github.token` access rather than explicitly defining it in the workflow permissions block, as preferred by user 2bndy5.