Support to run workflow_dispatch on external PR

Currently, it seems impossible to run a manual_workflow using an external PR.

In my case, we want to run checks on the branch before merging, but being public and with the need to use self-hosted (due to computation power required) runners, we can’t run the workflow on pull_request (to avoid a bad actor to modify the workflow when sending a PR and executing bad processes on the servers).
Our workflow is configured to run on push (for internal PR) and workflow_dispatch (which I hoped would allow to trigger the workflow for external PR but it doesn’t support it.

Any better solution ?

The pull_request_target event allows for workflow_dispatch-like behaviour but against a Pull Request – does this meet your needs?

This event runs in the context of the base of the pull request, rather than in the merge commit as the pull_request event does. This prevents executing unsafe workflow code from the head of the pull request that could alter your repository or steal any secrets you use in your workflow. This event allows you to do things like create workflows that label and comment on pull requests based on the contents of the event payload.

Unfortunately, it doesn’t for 2 reasons:

  • It runs against the pull request target (so it is not checking the code of the pull request itself)
  • The same reason why we don’t want to use pull_request is because it would run every time someone sends a PR, which could be dangerous in our case (this is the main reason I want to use manual trigger)

You can change this behaviour (in any event) by checking out the code for the Pull Request by reference: I believe the format is pull/:id/head.

- uses: actions/checkout@v2
    ref: pull/${{ }}/head

If you want to manually dispatch a Workflow for a Pull Request you could use workflow_dispatch with an input of the Pull Request id that the Workflow then composes the ref from (in the format above).

[…] because it would run every time someone sends a PR […]

GitHub has recently implemented security features that protect against abuse from first-time contributors so if your primary concern is first-time contributors this default behaviour may help.

Second, pull requests from first-time contributors will require manual approval from a repository collaborator with write access before any Actions workflows run. […] Once a collaborator with write access has reviewed the changes, they can approve the workflows to run for the current commit only. If the pull request is updated to a new commit, a new approval will be required.

Another option is middle-ground where all Pull Requests trigger the appropriate Workflow, and a condition in the Workflow validates whether the Workflow is “safe” to continue. For example that could be the presence of a label that you add to a Pull Request, or it could be the presence of approval from a code owner on the Pull Request. A benefit of this approach is that you may have Workflows that are always safe (e.g: linting documentation) and want those to run on every Pull Request commit without manual intervention.

I like the idea of the manual dispatch including the Pull Request id in it… That will solve my issue.

Concerning the first-time contributor protection, it is good, but not enough I think for our us case. It would be too easy for someone to submit a valid PR (like fixing the documentation) and then send a bad PR.

Using a workflow condition wouldn’t work if the actor is able to modify the workflow code. I suppose it would work with pull_request_target however…

Thank you :slight_smile:

1 Like