Help
cancel
Showing results for 
Search instead for 
Did you mean: 
Copilot Lvl 2
Message 1 of 8

Run GitHub action only on specific 'pull_request' actions

I tried this action today, which will clean up branches after they are merged: https://blog.jessfraz.com/post/the-life-of-a-github-action/

 

However, the GitHub action runs on every pull_request action: `opened`, `labeled`, `review_requestes` etc.

 

Since the GitHub action only needs to be run for the `closed` pull_request event, it would be nice to be able to narrow down the `on` command within the workflow.

 

Example of a narrower scope:

workflow "on pull request merge, delete the branch" {
    on = "pull_request.closed"
	
    resolves = ["branch cleanup"]
}

or

workflow "on pull request merge, delete the branch" {
    on = "pull_request"
only = "action=closed" resolves = ["branch cleanup"] }

 

Is this possible somehow, or on your roadmap?

7 Replies
Highlighted
GitHub Staff
Message 2 of 8

Re: Run GitHub action only on specific 'pull_request' actions

Thanks! Ah yes we have had a few requests for this and I will add another :) we are working on the right design for doing this
Pilot Lvl 1
Message 3 of 8

Re: Run GitHub action only on specific 'pull_request' actions

@jessfrazBig +1 for the ability to specify event types to trigger workflows. I have an Action that only needs to fire for pull_request "assigned" and "unassigned" events, but right now it's running on EVERY pull_request event, which is polluting the commit status area with unnecessary check runs.

Copilot Lvl 2
Message 4 of 8

Re: Run GitHub action only on specific 'pull_request' actions

I've stumbled upon this while reading the docs https://help.github.com/en/articles/contexts-and-expression-syntax-for-github-actions#example-using-...

 

Not entirely sure it answers your question though

 

Edit: the workflow is not triggered at all when the PR is closed/merged which is good for my use case but maybe not so good for yours.

Ground Controller Lvl 1
Message 5 of 8

Re: Run GitHub action only on specific 'pull_request' actions

I've just tried because I wanted to do something when the pr is merged to master and basically I had to setup 2 workflows, one for PRs that do all the checks and lints and one for push into master. so I opened a pr, the lints and tests started and after I merged it the other workflow was activated. of course this only work if you need to do your logic on merged PRs, if you delete it this may not work

Copilot Lvl 2
Message 6 of 8

Re: Run GitHub action only on specific 'pull_request' actions

Did anyone figure this out, and if such a filter is in place? I would like to start using the shiny and new GitHub Actions, but am blocked because I cannot do (or cannot figure out how to do) the most common pattern I have seen:

 

Run this workflow when a PR is opened, and when any new commit is applied to the branch (from local repo or forked) from which the PR is opened. So assigned, unassigned, closed, etc. none of it interests me. I want to run it when someone opens a PR from `foo/bar:br1` against my `me/bar:master`, or any time someone adds commits to `foo/bar:br1` (as long as a PR remains open, of course).

 

Has anyone figured this out?

GitHub Staff
Message 7 of 8

Re: Run GitHub action only on specific 'pull_request' actions

Yes, @deitch , this issue is quite old and is referencing the old HCL syntax.  In the new YAML syntax, you can indeed specify the types of events that you want to execute on for a particular trigger.  For example:

 

on:
  pull_request:
    types: [assigned]

Will only run when a pull request is assigned.

 

By default, `on: [ pull_request ]` will run only when a pull request is opened or updated, which sounds like what you're asking about.

 

You can find more information in the trigger documentation.

Copilot Lvl 2
Message 8 of 8

Re: Run GitHub action only on specific 'pull_request' actions

Thanks, @ethomson . I knew it was on the old HCL syntax (quite pleased you switched to yaml...), but the idea of "filter to actions on pull_request events" remained relevant.

 

I didn't realize that the `pull_request` event had been filtered by default to those activity types. Thanks for jumping in. Looks like it is ready to give a shot. Thanks!