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.
Related
GitHub Actions support running workflows for pull requests targets specific branches but the names of the branches must be specified, thus if we want it to run on repositories with default branch named main:
pull_request:
branches:
- main
I'm wondering if there's a way to share the same workflow across multiple repositories without the need to asking each repositories to specify their default branch name, and the workflow can work upon renaming default branches. Is there a way to just run the workflow upon pull requests to default branch without specifying all the possible default branch names across these repositories as below?
I want to avoid:
pull_request:
branches:
- main
- master
- develop
- dev
- i-dont-know-what-else
- ${{ remember-to-update-this-after-renaming-default-branch }}
I've tried listing all possible default branch names and use a variable but these are not elegant.
You can achieve this with the conditional github.ref == github.event.repository.default_branch.
Here's an example which only runs when a PR is merged into the default branch.
on:
pull_request:
types:
- closed
jobs:
example:
if: github.event.pull_request.merged && github.ref == github.event.repository.default_branch
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v3
I have a GitHub workflow as below.
name: Releaser
on:
push:
tags:
- 'v*.*.*'
This workflow will be triggered when I manually push a new tag like v1.1.1-rc1. It works fine.
Now, I want to have another workflow to replace the "manually push".
name: sync-tags
on:
workflow_dispatch:
push:
paths:
- TAGS
jobs:
steps:
- name: foo-example
uses: foo-example
This workflow will be triggered when there's a change made in the TAGS directory. The jobs will create a new tag like v1.1.1-rc1. It works fine as well. But, after the v1.1.1-rc1 is created by the sync-tags, the Releaser is not triggered.
I was wondering why the Releaser can be triggered by manually pushing tags but can't be triggered by tagging from other workflows?
I am having this same problem. It turns out this is intentional behavior from GitHub Actions.
… if a workflow run pushes code using the repository's GITHUB_TOKEN, a new workflow will not run even when the repository contains a workflow configured to run when push events occur.
Explicitly invoking the release workflow works! (Note: this needs GITHUB_TOKEN in the environment, which I happen to do for the entire workflow.)
- name: New tag & launch release process
run: |
echo "Tagging $new_tag"
git tag $new_tag
git push --tags
# Explicitly run our release workflow for this new tag
gh workflow run release.yml --ref $new_tag
My release workflow needed to be enhanced to allow manual runs. The workflow_dispatch: line in the on: section.
on:
push:
tags:
- 'v*.*.*'
workflow_dispatch:
To make sure we're building a release on a tag, I added if: github.ref_type == 'tag' to each job within the release workflow.
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
I have deployment action in my GitHub workflow.
I want to restrict this action trigger to the master branch only.
Here is a piece of workflow config:
on:
release:
branches:
- master
types:
- released
But when I'm publishing pre-release for any branch in my project it hits workflow immediately.
What's wrong with it? Please advice.
Tnx!
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