I am looking for a way to have a GitHub Action run when a PR is merged, the GitHub Action has to grab the PR description and store the data somewhere for later use.
Is there any way to do this through GitHub Actions without an API or webhook?
There are two approaches: Either run the workflow when a PR is closed with merge=true or run a workflow on the target branch if you know all pushes to the target branch go through a PR.
Run on PR Closed
You can trigger an action when a PR is closed like so:
on:
pull_request:
types: [closed]
The above event is triggered whether a PR was merged or closed without merging. Therefore, you still need to check that flag when running a job:
my_job:
build:
if: github.event.pull_request.merged == 'true'
Run on Target Branch
If you know all your PRs are merged into main and users cannot directly push to main, you might as well trigger your workflow on push events on main like so:
on:
push:
branches:
- main
Answer is great but slightly outdated, using 'true' did not work for me.
The following did the trick for me:
jobs:
publish:
if: github.event.pull_request.merged == true
Docs on this: jobs.<job_id>.if
Related
In our github repository, we have set up a protected environment named Sandbox, for which the main branch is the only allowed deployment branch. Now we want to deploy automatically to that environment if a pullrequest is merged into main (and the if the pullrequest in addition bears the label "Sandbox").
Our workflow is roughly as follows:
name: Pull Request Merged
concurrency:
group: ${{ github.ref }}
on:
pull_request:
types: [closed]
jobs:
deploy_to_sandbox:
if: |
github.event.pull_request.merged == true &&
contains(github.event.pull_request.labels.*.name, 'Sandbox')
name: Deploy to Sandbox
uses: ./.github/workflows/deploy.yml
with:
environment: Sandbox
secrets: inherit
The workflow is triggered as expected upon merging a PR, but somehow it tries to deploy from the feature branch instead of deploying from main. Since the environment is protected, the deployment fails accordingly. How can we achieve that the deployment uses the target branch (i. e. , main) that was merged into, instead of the source branch?
There’s no way to specify that a workflow should be triggered when a pull request is merged. the reason why it's the feature branch that gets deployed is because it's the one that triggers the workflow. However, because a merged pull request always results in a push, you can use the push event to accomplish your goal.
For example, let’s say that you want to run a workflow whenever a pull request is merged to your main branch. You can do something like this:
on:
push:
branches:
- main
also if you want to prevent push directly to main it's part of github pro plan.
I'm looking on a way to trigger a GitHub pipeline ONLY on successful pull request merge.
I have to move from Azure DevOps where I had some arguments like these:
condition: and(succeeded(), eq(variables['Build.Reason'], 'PullRequest'))
But I can't seem to find a way to do something similar on GitHub
EDIT:
So
on:
pull_request:
types: [closed]
jobs:
on-success:
if: ${{ github.event.pull_request.merged }}
steps:
- name: my-step
run: echo "Hello World!"
Works but only on manually accepted PRs, which is not what I need.
The answers should work with git CLI if you do:
git checkout main
git merge dev
and then accept the changes and commit+push
Then the actions should be triggered and these last answers doesn't work with that.
The try using this to double check for sucess.
on:
pull_request:
types: [closed]
branches: [main]
jobs:
on-success:
if: ${{ github.event.pull_request.conclusion == 'success'}}
steps:
https://docs.github.com/en/github-ae#latest/actions/using-workflows/events-that-trigger-workflows#running-your-workflow-when-a-pull-request-merges-1
on:
pull_request_target:
types:
- closed
jobs:
if_merged:
if: github.event.pull_request.merged == true
runs-on: ubuntu-latest
steps:
- run: |
echo The PR was merged
IMHO you cannot do this.
When you're running git merge you're just merging branches in git, you're not merging a Pull Request in GitHub. Git is the underlying version control system used by GitHub, but git itself has no concept of pull requests.
If you want to trigger a GitHub action, you need to generate an event on the GitHub pull request, therefore you need to use github's own CLI, not git CLI. See gh pr merge https://cli.github.com/manual/gh_pr_merge
You can use push trigger. Please refer to https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#push
On the branch that the Pull request will be merged, you can add the condition and it will get triggered.
Ex:
on:
push:
branches:
- 'main'
- 'releases/**'
We want to adopt Trunk Based Development branching policy as explained here.
As a part of our solution we want to trigger Azure pipeline whenever a new release branch is created from master (trunk): for example releases/R.1
Our current yaml for said pipeline looks like this:
trigger:
branches:
include:
- releases/*
...
Unfortunately it doesn't trigger when branch is created. I suspect it will trigger when we make changes to release branch, but according to Trunk Based Development we plan to only merge cherry-picked bugfixes/hotfixes from master. Is there a way to trigger pipeline on branch creation?
Refer to this doc: Behavior of triggers when new branches are created
Here is the behavior when you push a new branch (that matches the branch filters) >to your repository:
If your pipeline has path filters, it will be triggered only if the new branch has >changes to files that match that path filter.
If your pipeline does not have path filters, it will be triggered even if there are >no changes in the new branch.
To trigger the pipeline when a new branch created, you need to remove the path filter and only set branch filter.
For example:
trigger:
- release/*
pool:
vmImage: ubuntu-latest
steps:
- script: echo Hello, world!
displayName: 'Run a one-line script'
I have this github action that I think is wrong and didn't run for tags.
name: CI
on:
push:
branches:
- master
- /^v[0-9]+\.[0-9]+\.[0-9]+$/
I think that should be:
name: CI
on:
push:
branches:
- master
tags:
- v.*
My question is, after I update this ci config, how can I re-run this CI so that it runs on the tags? Or should I create a new tag just because I want this CI to run on it (I think this sounds bad since it means I created another release/tag without any actual updates, only CI config)?
Any help would be greatly appreciated!
Since July 2020, you could add a workflow_dispatch event and trigger manually your GitHub ACtion
(the workflow must exist on the default branch for the "Run workflow" button to appear)
That way, you can try and see if it does run based on your new tag criteria.
I'm setting up Github actions for a few of my projects.
The flow I'd like to achieve is:
A developer clicks on the "Merge pull request" button
A Github action testing workflow will take place
If the tests pass - The merge is executed
The reason for this kind of flow, is I wouldn't like the tests to run on each commit pushed to the branch. I want the flow to run only when trying to merge.
My question is:
Is there a way to manually execute a workflow only when trying / wanting to merge, and making sure the branch can be merged into master if and only if the tests have passed?
Unfortunately, there's no merged or merge_attempt activity type on the pull request event (yet). Even if there was, I don't believe GitHub has a way to block merges on the completion of a workflow (yet).
What I would suggest as a workaround here is to run your test 1. after the fact on pushes to the master branch, and 2. on pull_request events with certain activity types which indicate that the user is likely to attempt a merge soon. For example, ready_for_review or review_requested.
Something like this:
name: tests
on:
push:
branches:
- master
pull_request:
branches:
- master
types:
- ready_for_review
- review_requested