ci: auto-run workflow for fork PRs

[Ma77Ball]

What changes were proposed in this PR?

The build workflow now enforces a stricter permission model for fork PRs that modify the workflow file. A check-permissions job is added as a required predecessor to all build jobs (frontend, scala, python). If a PR modifies .github/workflows/github-action-build.yml and the author is not a committer (i.e., does not have write, maintain, or admin permissions), the workflow fails with an error requiring a committer to review and manually re-run it. PRs that do not modify the workflow file continue to run automatically as before.

Any related issues, documentation, discussions?

Closes: #4279

How was this PR tested?

Verified that the check-permissions job correctly detects workflow file changes and checks the actor's repository permissions. Confirmed that PRs modifying the workflow are blocked for non-committers, and that all other PRs are unaffected.

Was this PR authored or co-authored using generative AI tooling?

Resolved comments with Claude Sonnet 4.6

[Yicong-Huang]

The PR title is kind of broken, it will be nice to make it concise.

[Ma77Ball]

@chenlica or @Yicong-Huang, please rerun the workflow. I removed the safe-to-test label.

[Yicong-Huang]

I'm not sure I follow how this works now. The pr description sounds like it require a committer to add the safe to run label manually. It's still an additional step. It will be good if we can trigger CIs on PRs from anyone/ any fork, no matter if that is from committer or not, and no need for committer to manually approve it.

[Ma77Ball]

@Yicong-Huang, I've updated the PR description and removed the safe-to-test label due to a potential security concern.

The original intent was to automatically run the GitHub workflow on any PR that didn't modify the workflow itself, with the safe-to-test label serving as a committer override for PRs that did. However, this approach places too much implicit trust in PRs that both run and modify the workflow, which could introduce vulnerabilities.

The updated design takes a simpler, safer approach: if the GitHub workflow has been modified, it will not run automatically and will require explicit committer review and approval before execution.

[Yicong-Huang]

However, this approach places too much implicit trust in PRs that both run and modify the workflow, which could introduce vulnerabilities.

make sense. since we are running actions in our main repo, it is a good idea to let committer approve altered action/workflows.

Verified that the check-permissions job correctly detects workflow file changes and checks the actor's repository permissions. Confirmed that PRs modifying the workflow are blocked for non-committers, and that all other PRs are unaffected.

How did you verify though?

[Yicong-Huang]

also currently, how do I (with committer privilege), approve the modified actions to execute? the `check-permissions` step is failing.

[Ma77Ball]

I checked by raising a PR in my local fork, and it worked. Let me look and submit a fix.

[Yicong-Huang]

I checked by raising a PR in my local fork, and it worked. Let me look and submit a fix.

sg! It will be nice to include the link to your test PR in your fork, in the PR description. That way we have some reference of what's being tested. Thanks!

[Ma77Ball]

If you rerun the build workflow, it should work, as I have edited the workflow; it will fail until a committer initiates the GitHub workflow. There should be a button to rerun the workflow, or you might need to go into the actions tab and run the build workflow on this pr manually.

[Ma77Ball]

@Yicong-Huang, the current workflow fails because I triggered it and edited the build workflow.

After you run the workflow, it should pass.

[Yicong-Huang]

After you run the workflow, it should pass.

Hmm, how do I run it? I don't think there is a button.. I could manually go to actions page to dispatch it, but it would be very inconvenient.

[Ma77Ball]

I updated the code so that four events can trigger the workflow: a push to main or ci-enable/**, a pull request being opened/updated, a /safe-to-test comment on a PR, or a manual workflow_dispatch. The check-permissions job runs first in all cases. For push and dispatch, it passes straight through. For a pull request, it checks if the build workflow file was modified; if not, it passes; if yes, it checks whether the actor is a committer and fails with an error message directing them to comment /safe-to-test if not. For a /safe-to-test comment, it verifies the commenter is a committer and fails if not. Once check-permissions passes, the frontend, Scala, and Python jobs all run against the correct PR.
FYI: There is no way I know of to keep the run workflow button and build an auto check function in GitHub workflows. Now, committers for PRs that edit workflows can just comment /safe-to-test.

[Ma77Ball]

/safe-to-test