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.
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'd like a Github action to run on Pull Request to a specific base branch, but from another specific head branch.
name: Run production tests
on:
push:
pull_request:
branches:
- main
jobs: ...
However, I specifically want something like this to run when a branch called develop is PR'd against main, not just every time something is PR'd to main.
Is such a workflow possible? I might be missing it, but I don't see a way to target head branches in the docs.
From the documentation, I could not find any filters for the head branch. But this is doable with if conditions for jobs.
For example
name: Run production tests
on:
pull_request:
branches:
- main
jobs:
build:
if: ${{ github.head_ref == 'develop'}}
runs-on: ubuntu-latest
steps:
- name: Run a multi-line script
run: |
echo "Do something here"
I have a repository with Dependabot in it, that opens PR on version updates, etc which I would like to keep.
In the same repository, I have a GitHub Action for Pull Requests for my team to use.
My issue is that the Dependabot keeps triggering the Pull Request action no matter what I tried.
My PR action have to be triggered on staging branch pull requests, like so:
name: Pull Request
on:
pull_request:
branches:
- staging
So I can't use both on pull_reuqest AND branches_ignore - as stated in the documentation
Workflow attempts I have tried so far that unfortunately haven't worked:
name: Pull Request
on:
pull_request:
branches:
- staging
- '!dependabot/**'
name: Pull Request
on:
pull_request:
branches:
- staging
jobs:
Build:
if: github.actor!= 'dependabot-preview[bot]'
name: Build
runs-on: ubuntu-latest
steps:
- name: Check out code
uses: actions/checkout#v2
I have also tried excluding the Dependabot user like so:
if: github.actor!= 'depbot'
Would love some insights or answers on how you have dealt with this issue.
Thanks!
I guess there were many changes over the years and you can find outdated ways all over the web. The actual way is documented in the Dependabot documentation
if: ${{ github.actor != 'dependabot[bot]' }}
Note that nowadays you can also check the github.triggering_actor - if you want workflow to be skipped if Dependabot triggered it, but want to be able to manually trigger it on a PR that was opened by Dependabot
I'm currently using the "git-flow" branching model outlined here. Following that model, once I've completed work on a feature branch, I'd like to add new GitHub actions to that branch (for example, to run my feaure's automated tests) before the branch is merged.
Following the branching model, I don't want to define the actions in a workflow file on the default branch before that feature branch is merged into it. Ideally I want to add the actions on the feature branch itself before the merge, but this doesn't appear to work.
I've added the below sample workflow to my feature branch, but GitHub does not detect it. Am I missing something here, or can workflows only detected and run once they're on the default branch? If the latter is true, do people generally merge their branches, then add workflows for them?
# Name workflow
name: Test workflow
# Read only permissions
permissions: read-all
# Triggered once every 15 minutes
on:
workflow_dispatch:
schedule:
- cron: '15 * * * *'
# Listing of jobs to be run
jobs:
# Just output the Python version for now.
python-tests:
name: Python Tests
runs-on: ubuntu-latest
# Use the environment configured with secrets
environment: python-test-environment
# Set the working directory?
defaults:
run:
working-directory: tests
steps:
# Checkout the repository
- name: Checkout
uses: actions/checkout#v2
ref: 'dev-tests'
# Configure Python
- name: Set up Python 3.7
uses: actions/setup-python#v2
with:
python-version: 3.7
# Output the Python version
- name: Display version
run: python -c "import sys; print(sys.version)"
Update: I can see now that the "schedule" trigger only works on the default branch. However, removing it and just using the workflow_dispatch trigger still (on the feature branch YML file) still does not show the workflow on GitHub.
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.