Menu
Say I have 2 branches, a feature branch and a develop branch.
There's no SLA on feature branch normally, meaning I can push broken code up to it all day long and no CI build should be triggered.
Then I open a PR into develop. I trigger a CI build action on pull_request: created. Let's say this build fails. By default I can't merge the PR, which is correct.
Now I want to push edits to feature branch to update the PR. I want these pushes to trigger a CI build (because we're now working inside an open PR). I don't want to allow the PR to proceed/be merged until these push-CIs pass.
How can I do that in GitHub Actions? I tried on pull_request: edited but that didn't work for me.
I'm looking for the functional equivalent of:
on:
push:
if: inside_open_pr
906
Earlier this week, GitHub announced a new feature which allows developers to trigger workflows manually from within the “Actions” tab.
If you do want to trigger a workflow from within a workflow run, you can use a personal access token instead of GITHUB_TOKEN to trigger events that require a token. You'll need to create a personal access token and store it as a secret.
We can now manually trigger our GitHub actions workflow using curl from the command line. If we do not specify the types property of the repository_dispatch trigger, our workflow will run in response to any repository_dispatch event. Otherwise it will limit for particular event type.
The only differences are the branch check via github.ref, and the specifics of steps. I happen to be using my own Github Action tjtelan/zola-deploy-action but your steps could consist of anything you want to do differently between pull requests and push to your “special” branch. Here’s a template that you can use for your own push vs PR workflows.
These events can be: Events that occur outside of GitHub and trigger a repository_dispatch event on GitHub For example, you can configure your workflow to run when a push is made to the default branch of your repository, when a release is created, or when an issue is opened.
One of the variables we can use in out expression is github.event_name, this variable is the name of the event that triggered the workflow run. In our example this can either be push or pull_request. So what we can do is check that the event is always a push on our step.
Use the event pull_request and don't specify activities or specify the activity synchronize:
on:
pull_request:
Note: By default, a workflow only runs when a
pull_request's activity type isopened,synchronize, orreopened. To trigger workflows for more activity types, use the types keyword.
source
if you push a new commit to the HEAD ref of a pull request then this “synchronize” event will be triggered. This is because the system is syncing the pull requests with the latest changes. This will NOT trigger if the base ref is updated.
source
If you also need to react to a change of the base branch, then you have to add the activity edited.
source
151
If pull_request is not an option, you can try using https://github.com/marketplace/actions/get-current-pull-request
1
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
