assertSafePrCheckout() appears to validate that the commit SHA that will be checked out for a pull_request_target event isn't equal to the SHA of the PR head:
|
!!input.commit && prShas.includes(input.commit.toLowerCase()) |
However, this seems to break when using rebase merges on PR closed events, as when a fast-forward merge is possible, the target repo head SHA will match the PR head SHA. The
pull_request_target job will then run on a SHA that is equal to both the PR head SHA and the target branch SHA, which causes this safety check to trip false-positively.
We always use rebase merges for the https://github.com/SerenityOS/serenity repository.
Here is an example of such a failed run: https://github.com/SerenityOS/serenity/actions/runs/29007909349/job/86092844021.
This is the yaml for this workflow: https://github.com/SerenityOS/serenity/blob/master/.github/workflows/label-pull-requests.yml. It simply updates labels and never needs to access the PR branch, so it should be safe.
assertSafePrCheckout()appears to validate that the commit SHA that will be checked out for apull_request_targetevent isn't equal to the SHA of the PR head:checkout/src/unsafe-pr-checkout-helper.ts
Line 64 in e8d4307
However, this seems to break when using rebase merges on PR closed events, as when a fast-forward merge is possible, the target repo head SHA will match the PR head SHA. The
pull_request_targetjob will then run on a SHA that is equal to both the PR head SHA and the target branch SHA, which causes this safety check to trip false-positively.We always use rebase merges for the https://github.com/SerenityOS/serenity repository.
Here is an example of such a failed run: https://github.com/SerenityOS/serenity/actions/runs/29007909349/job/86092844021.
This is the yaml for this workflow: https://github.com/SerenityOS/serenity/blob/master/.github/workflows/label-pull-requests.yml. It simply updates labels and never needs to access the PR branch, so it should be safe.