Repository navigation
Onboard slangpy to slang PR board-sync workflow - #1084
Conversation
Replace the open-only add-pr-to-project workflow with thin callers that drive Status, Source, and assignment via shader-slang/slang's shared pr-board-sync engine.
📝 WalkthroughWalkthroughChangesPR project-board automation now uses dedicated workflows for lifecycle events, completed checks, commit statuses, fork reviews, and scheduled sweeps. The previous direct project workflow was deleted. Synchronization delegates to a reusable board-sync workflow. PR board synchronization
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: a53109b8-6f8e-453a-8cb3-5621fd9f7a73
📒 Files selected for processing (6)
.github/workflows/add-pr-to-project.yml.github/workflows/pr-checks-complete.yml.github/workflows/pr-commit-status.yml.github/workflows/pr-maintenance.yml.github/workflows/pr-review-fork-apply.yml.github/workflows/pr-review-fork-bridge.yml
💤 Files with no reviewable changes (1)
- .github/workflows/add-pr-to-project.yml
ccummingsNV
left a comment
ccummingsNV
left a comment
There was a problem hiding this comment.
I'm probably not the best to give this a detailed review, but nothing dodgy stands out - LGTM
Allow @master / tag refs for shader-slang/slang reusable workflows and first-party GitHub actions so CodeRabbit/zizmor stop flagging unpinned-uses.
| unpinned-uses: | ||
| config: | ||
| policies: | ||
| shader-slang/slang/*: ref-pin |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
rg -n '^\s*uses:\s*shader-slang/slang/' .github/workflowsRepository: shader-slang/slangpy
Length of output: 725
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== .github/zizmor.yml =="
cat -n .github/zizmor.yml
echo
echo "== all repository-local zizmor workflow references =="
rg -n '^\s*uses:\s*' .github/workflows .github || trueRepository: shader-slang/slangpy
Length of output: 9057
🌐 Web query:
zizmor ref-pin policy configuration symbol refs owner/repo/* pattern
💡 Result:
In zizmor, the ref-pin policy is a configuration setting for the unpinned-uses audit that allows specific GitHub Actions references to be pinned by branch or tag (symbolic references) rather than requiring a mandatory full commit SHA hash [1][2]. Configuration Details You can define policies for uses clauses within your zizmor configuration file (.github/zizmor.yml or zizmor.yml) under the rules.unpinned-uses.config.policies object [1][3][4]. Each entry maps a repository pattern to a specific policy [1][2]. Valid policies include: ref-pin: Permits pinning by branch, tag, or SHA [1][2]. hash-pin: Strictly requires pinning by full commit SHA [1][2]. any: Removes all pinning requirements for the matched pattern [1][2]. The owner/repo/* Pattern The owner/repo/* pattern is used to match all uses clauses originating from a specific repository, regardless of the subpath or reference used [4][5]. For example, a rule defined as actions/: ref-pin would allow symbolic references (like @v4) for any action within the actions organization [6][5]. General Configuration Structure To configure these policies, use the following YAML structure in your configuration file: rules: unpinned-uses: config: policies: "owner/repo/": ref-pin "other-owner/": hash-pin "": hash-pin Specificity and Matching Zizmor evaluates these patterns based on specificity, meaning more specific patterns (e.g., owner/repo/subpath) take precedence over broader ones (e.g., owner/repo/* or owner/*) [2][4][7]. If a uses clause does not match any explicit policy in your configuration, it falls back to the default audit policy, which typically requires hash-pinning [1][6][2]. Since version 1.20.0, the default behavior of zizmor is to require hash-pinning for all actions [1]. Users who wish to continue using symbolic references for trusted repositories must explicitly add them to their configuration as shown above [1][6].
Citations:
- 1: https://docs.zizmor.sh/audits/
- 2: https://github.com/zizmorcore/zizmor/blob/563b7b25/crates/zizmor/src/config/mod.rs
- 3: https://exasol.github.io/python-toolbox/main/user_guide/features/managing_dependencies/zizmor_configuration.html
- 4: https://docs.zizmor.sh/configuration/
- 5: https://github.com/zizmorcore/zizmor/blob/563b7b25/docs/configuration.md
- 6: https://github.com/zizmorcore/zizmor/blob/main/docs/release-notes.md
- 7: feat(uses): add glob pattern support for repository matching zizmorcore/zizmor#1559
Narrow the Slang repository exception.
shader-slang/slang/* allows any Slang subpath to use a mutable reference. Current callers also use @master for /.github/actions/claude-code-runner, so restrict the ref-pin policy to only the trusted referenced paths instead of the full repository.
Schedule mode:sweep via slang's reusable pr-board-sync so this repo's open PRs get the same nightly backstop as slang.
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: ae2e895b-586d-4ee7-9549-004e7644cdb4
📒 Files selected for processing (1)
.github/workflows/pr-sweep-nightly.yml
|
|
||
| jobs: | ||
| board-sweep: | ||
| uses: shader-slang/slang/.github/workflows/pr-board-sync.yml@master |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== workflow file =="
cat -n .github/workflows/pr-sweep-nightly.yml
echo
echo "== references to SLANG_PR_BOT_TOKEN and reusable workflows =="
rg -n "SLANG_PR_BOT_TOKEN|pr-board-sync|workflow_dispatch|security|permissions:" .github/workflows -SRepository: shader-slang/slangpy
Length of output: 4684
🌐 Web query:
GitHub Actions reusable workflows secret sharing SLANG_PR_BOT_TOKEN organization Projects read/write pull request issue write scopes commit SHA immutable ref
💡 Result:
When using GitHub Actions reusable workflows, secret sharing and permission management require specific configurations to ensure security and functionality [1][2][3][4]. Reusable Workflow Secret Sharing Secrets are not automatically passed to reusable workflows unless explicitly mapped or inherited [1][2][5]. 1. Explicit Mapping: Use the secrets keyword in the caller workflow to map specific secrets to the called workflow's inputs [1][6]. This is the recommended practice for security, as it limits the exposure of secrets to only what is necessary [6][4]. 2. Secret Inheritance: Using secrets: inherit in the caller workflow passes all secrets the caller has access to, including organization, repository, and environment secrets, to the called workflow [2][7][5]. This should be avoided if you do not fully trust the repository containing the reusable workflow [4]. SLANG_PR_BOT_TOKEN and Permissions In configurations such as the slang/slang project, a custom PAT like SLANG_PR_BOT_TOKEN is often used to perform organization-level tasks (e.g., managing Projects, Issues, and Pull Requests) that the default GITHUB_TOKEN cannot perform [8][9]. - Permissions: To grant a reusable workflow the necessary scopes (e.g., contents: write, pull-requests: write), you must explicitly define these permissions in the calling job [10]. Even if the reusable workflow requires these permissions, the caller must explicitly grant them at the job level [10]. - Least Privilege: It is a best practice to set permissions: {} at the top level of the caller and reusable workflows to disable the default GITHUB_TOKEN permissions, then grant only the required scopes at the specific job level [8][9]. Commit SHA and Immutable References To prevent supply chain attacks and ensure consistent execution, reusable workflows should be referenced by an immutable commit SHA (e.g., uses: org/repo/.github/workflows/workflow.yml@a1b2c3d4...) rather than a mutable tag or branch name [3][11][4]. Pinning to a SHA ensures that the workflow logic remains identical across runs and protects against unauthorized modifications to tags or branches [3][4]. Summary of Best Practices - Pin all reusable workflows to an immutable commit SHA [3][4]. - Prefer explicit secret mapping over secrets: inherit [6][4]. - Explicitly define job-level permissions in the caller, even for reusable workflows [10]. - Use least-privilege configurations (permissions: {}) for both callers and reusable workflows [8][9].
Citations:
- 1: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows
- 2: https://docs.github.com/en/enterprise-cloud@latest/actions/how-tos/reuse-automations/reuse-workflows
- 3: https://github.com/github/docs/blob/main/content/actions/concepts/workflows-and-actions/reusing-workflow-configurations.md
- 4: https://cve.optibot.re/blog/github-actions-security-hardening-2026
- 5: https://github.com/github/docs/blob/main/content/actions/how-tos/reuse-automations/reuse-workflows.md
- 6: Passing in secrets to reusable workflow does not work actions/runner#2709
- 7: [BUG] Environment-scoped secrets unreachable from reusable workflow without secrets: inherit, despite called job declaring environment actions/runner#4453
- 8: Add reusable PR board-sync workflow (status + assignment) for org-wide reuse slang#11740
- 9: shader-slang/slang@5c30d43
- 10: fix: grant contents/pull-requests write to sync_actions reusable workflow call github/gh-aw#20613
- 11: https://docs.github.com/en/actions/reference/workflows-and-actions/reusing-workflow-configurations
Pin the privileged reusable workflow to an immutable commit.
The reusable workflow at line 27 uses the mutable master ref and receives SLANG_PR_BOT_TOKEN. A later shader-slang/slang change can alter the workflow that reads this token, whose permissions span organization Projects and pull-request/issue write access. pin the call to a reviewed full commit SHA.
Suggested fix
- uses: shader-slang/slang/.github/workflows/pr-board-sync.yml@master
+ uses: shader-slang/slang/.github/workflows/pr-board-sync.yml@<reviewed-full-commit-sha>Source: Path instructions
jkwak-work
left a comment
jkwak-work
left a comment
There was a problem hiding this comment.
Looks same to the others.
LGTM
4 participants
Summary
add-pr-to-project.ymlworkflow with thin callers for slang's reusablepr-board-sync.yml(Status, Source, assignment, fork-review relay).pr-checks-complete.ymlto slangpy's gating Actions workflows (ci,checks).pr-sweep-nightly.ymlso this repo gets its own nightlymode: sweepbackstop (enumerates this caller's open PRs viacontext.repo).SLANG_PR_BOT_TOKENandpermissions: {}per the slang onboarding templates.Test plan
SLANG_PR_BOT_TOKENis available toshader-slang/slangpymain, open a test PR (or use an existing one) and verify it appears on the Slang PR Tracking board with Source/Statuschecksorciand confirm Status moves to Snagged (and recovers on green)PR Board Sweep (nightly)viaworkflow_dispatchand confirm open PRs reconcileAdd PR to Project Boardworkflow no longer runs