Gate workflow changes from forks behind committer approval

[Ma77Ball]

Task Summary

Forked PRs can execute arbitrary code in CI by modifying the build workflow file, since GitHub Actions runs the modified workflow on the fork's branch. This gives external contributors potential access to repository secrets and the CI environment without any maintainer review.
The current build workflow has no protection against this; any fork PR that modifies .github/workflows/github-action-build.yml will run the modified workflow immediately. This creates two problems:

Inefficiency: Since there is currently no automated trust mechanism, contributors must constantly wait for a committer to manually trigger CI runs on their PRs, leading to unnecessary back-and-forth and slowing down both contributors and committers.

Priority

P2 – Medium

Task Type

• Code Implementation
• Documentation
• Refactor / Cleanup
• Testing / QA
• DevOps / Deployment

[Ma77Ball]

High-Level design diagram:

flowchart TD
    A([push / pull_request / dispatch]) --> B{check-permissions}
 
    B -->|no write access + <br>  workflow modified| F([fail])
    B -->|no write access + <br> safe-to-test labeled| G([fail, remove label])
    B -->|pass| C[frontend]
    B -->|pass| D[scala]
    B -->|pass| E[python]
 
    C --> H([build complete])
    D --> H
    E --> H

Loading

High-Level Explanation:

1. The build workflow runs on every push, pull request, and manual dispatch.
2. Before any build job starts, a permissions check gate runs. It blocks the build if a PR modifies the build workflow file and the author doesn't have write access, or if someone without write access applies the safe-to-test label (which also automatically removes it).
3. If the gate passes, the three build jobs frontend, Scala, and Python, run in parallel. All three must succeed for the build to complete.

[Ma77Ball]

Low-level design diagram for check-permissions:

flowchart TD
    A([PR opened or synced]) --> B{workflow file<br>modified?}
    B -->|no| P([pass, output SHA])
    B -->|yes| C{actor has<br>write access?}
    C -->|yes| P
    C -->|no| F([fail])
 
    L([safe-to-test labeled]) --> D{actor has<br>write access?}
    D -->|yes| P
    D -->|no| R([fail, remove label])
 
    P --> E[frontend / scala / python<br>checkout at SHA]

Loading

Low-Level Explanation:

• For regular PRs, it diffs the changed files against the base branch. If .github/workflows/github-action-build.yml was touched, it checks whether the actor has write/maintain/admin access. If not, the build is blocked.
• For labeled PRs, when safe-to-test is applied, it checks who applied it. If that person lacks write access, the label is deleted, and the build is blocked. This prevents a contributor from applying the label themselves to bypass the workflow check.
• On SHA, the gate resolves and outputs github.sha (the commit being tested). All three build jobs, then checkout that exact SHA via ref: ${{ needs.check-permissions.outputs.sha }}, ensuring every job runs against the same commit regardless of when the jobs start.

[Ma77Ball]

@Yicong-Huang and @chenlica, any thoughts or suggestions on the current design and approach?