I have created the following GitHub Actions workflow.
name: Testing CI
on:
push:
branches: [ my-branch ]
Here in branches: [my-branch] I am putting the name of the current branch.
But I want the workflow file to automatically take the name of the current branch.
Is there a parameter I can pass branches: [my-branch] here to automatically take the branch name?
You should not specify a branch name, then, in order for your action to run on push for all branches: on: [push]
Then you can use EthanSK/git-branch-name-action in order to get the current branch name.
That action uses process.env.GITHUB_REF,
and is the equivalent of this solution:
export GIT_BRANCH=$(echo ${GITHUB_REF:-dev} | sed s/.*\\///g).
Just use this And it will run on push of any branch:
on: [push]
Related
How to apply branches-ignore and paths-ignore on GitHub Actions? For example, if I have the following source tree:
|-src\
|----reports\
|-------<foo>DailyReports.ts
I want to only deploy that to production (master branch) but NOT staging (staging branch).
Any advice and insight is appreciated.
You won't be able to achieve what you want with ON trigger configuration alone. Therefore the implementation below wouldn't work as it would trigger for push to the specified path OR for push to the master branch, but not only for both:
on:
push:
path:
- 'src/reports/*DailyReports.ts'
branches:
- master
In that case, you could do it by using only one trigger at the workflow level, and check the other condition with an IF expression.
For example by doing this:
on:
push:
path:
- 'src/reports/*DailyReports.ts'
jobs:
job1:
runs-on: ...
if: github.ref == 'refs/heads/master' # run this job only for the master branch
steps:
...
Or by checking the branch at the workflow level, and then use something like this path-filter action to check if the file or directory has been updated or not before performing some operation.
I personally suggest the first option (cf example), as it's less verbose.
Note: If the src/reports/*DailyReports.ts path isn't working as expected, you can use the filter pattern cheat sheet to find the right expression.
I have a Github Action that deploys my app from the main branch when there is a push to it or a merge from a pull request:
'on':
push:
branches:
- main
jobs:
build_and_deploy:
What I am trying to accomplish is to only run the action if the pull request comes from a branch that does not contain the string "nodeploy/" in its name.
I tried this:
'on':
push:
branches:
- main
jobs:
build_and_deploy:
if: ${{ !startsWith(github.head_ref, 'nodeploy/') }}
but it didn't work.
I believe it doesn't work because the value of github.head_ref is always main in this case.
Are there any solutions to this?
I found a solution. As suggested in the comments, I checked the message in the head commit.
'on':
push:
branches:
- main
jobs:
build_and_deploy:
if: ${{ !contains(github.event.head_commit.message, 'nodeploy/') }}
And now it does what I wanted.
Be aware that if you change the automatically generated merge message it won't work.
I'm using Github actions with two workflows: CI and CD. The CI workflow is triggered for new tags like v1.1.1 and pull requests to develop and hotfix branches.
name: CI
on:
push:
tags: v[1-9]+.[0-9]+.[0-9]+
pull_request:
branches: [develop, hotfix*]
The CD workflow is triggered when the previous workflow (CI) is completed.
name: CD
on:
workflow_run:
workflows: ['CI']
push:
tags: v[1-9]+.[0-9]+.[0-9]+
types:
- completed
Currently, my goal is to generate packages (Docker images) based on the name of the new tag. I'm trying to read the new tag name in the CD workflow using the action dawidd6/action-get-tag#v1:
- name: Get tag
id: tag
uses: dawidd6/action-get-tag#v1
- name: Use tag
run: echo ${{steps.tag.outputs.tag}}
But I'm getting the following error:
Run dawidd6/action-get-tag#v1
env:
IMAGE_NAME: open-tuna-api
Error: Not a tag ref (refs/heads/master)
My question is: how to read the tag name in my CD workflow that is triggering after the CI workflow?
First of all, you can get the tag without using an action, with ${GITHUB_REF##*/}.
Sample test workflow:
name: Experiment
on:
push:
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Debug
run: echo "Works. Tag is ${GITHUB_REF##*/}"
As for the chained workflows you mention - I am not sure it is possible to get the tag of the ancestor workflow, since the documentation mentions it is triggered on the default branch, and the last commit on that branch.
I want my workflow to trigger on a push only if there are changes made to a specific directory. Is this possible, what am I missing? I tried doing something like what you see below, but it didn't fire the trigger.
name: ABC
on:
push:
branches: [master/my-directory]
pull_request:
branches: [ master ]
push has a property called paths:
name: ABC
on:
push:
branches:
- master
paths:
- my-directory/**
This will only trigger on pushes to the master branch with changes in the my-directory directory tree. See the filter pattern cheat sheet for all possible filter patterns.
Github actions is still in beta and pretty new, but I hope someone can help regardless. I thought it would be possible to run github actions on the master branch and on pull requests, like this:
on:
pull_request
push:
branches: master
But this doesn't work, and throws the error
yaml: line 4: mapping values are not allowed in this context
. Instead I can only get it to work like this:
on: [pull_request, push]
What am I doing wrong? Thanks.
I think you are just missing a colon after pull_request. This works for me.
on:
pull_request:
push:
branches: master
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v1
- name: Test
run: echo "done"
Explanation
Each trigger has to be defined as a property that defines an object.
Each object defines overrides for default settings.
There are 3 possible syntax you can use:
Minimal syntax:
on:
pull_request:
push: { branches: [master] }
Explicit syntax:
on:
pull_request: {}
push: { branches: [master] }
Extendable syntax:
on:
pull_request:
push:
branches:
- master
When using a version control system the latter may be most useful as diff viewers can always easily distinguish* between different lines.
*Although modern diff viewers can also easily distinguish inline differences.