Push event doesn't trigger workflow on push paths (github actions) - github-actions

I'm currently testing Github Actions workflows on this repository.
Context
I'm trying to use this workflow (1st):
on:
workflow_dispatch:
jobs:
job:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- run: |
date > report.txt
git config user.name github-actions
git config user.email github-actions#github.com
git add .
git commit -m "generate or update report.txt file"
git push
To trigger this workflow (2nd):
on:
push:
paths:
- '**/report.txt'
pull_request:
paths:
- '**/report.txt'
jobs:
job:
runs-on: ubuntu-latest
steps:
- run: echo "Report .txt file has been updated"
What I tried
I followed the Github Action Documentation to implement the 2nd workflow with a Filter Pattern.
When I update the report.txt file locally, then commit and push the code to the repository, the 2nd workflow triggers.
However, I don't understand why the 2nd workflow doesn't trigger when the 1st workflow is completed, even with the report.txt file being updated on the default branch.
EDIT: I know I could trigger the 2nd workflow using others trigger event types (examples: repository_dispatch or workflow_run). But I'm trying to do it from a git push command on another workflow.
Question
Did I miss something on the 1st workflow to make it trigger the 2nd, or should I add something on the 2nd workflow to make it being triggered by the 1st one?

No, you didn't miss anything in your workflows.
You just need a different token.
When you use actions/checkout, it uses the GITHUB_TOKEN for authentication, and according to the documentation it doesn't trigger a new workflow run:
When you use the repository's GITHUB_TOKEN to perform tasks on behalf
of the GitHub Actions app, events triggered by the GITHUB_TOKEN will
not create a new workflow run. This prevents you from accidentally
creating recursive workflow runs.
To make it work, you need to generate a PAT (Personal Access Token), store it in your repository secrets, and use it in your checkout step:
- uses: actions/checkout#v2
with:
token: ${{ secrets.YOUR_PAT_TOKEN }}

There are three ways of authentication within a GitHub action.
1. GITHUB_TOKEN
The GITHUB_TOKEN is always available and implicitly defined by GitHub.
- uses: actions/checkout#v3
with:
token: ${{ secrets.GITHUB_TOKEN }}
It has limited permissions, though, as it cannot trigger new workflow runs. This is why your second workflow does not start.
2. PAT (Personal Access Token)
A personal access token can be generated in your developer settings. You can then add it as an encryped secret, e.g. PAT_TOKEN to the GitHub project and use it instead of the GITHUB_TOKEN:
- uses: actions/checkout#v3
with:
token: ${{ secrets.PAT_TOKEN }}
Subsequent push actions in the same workflow will then trigger any configured GitHub workflow as if they were pushed manually.
Be aware that the personal access token has access to all of your repositories and hence can be a potential security risk.
3. Deploy key
You can generate a dedicated SSH keypair and add it to the repository as a Deploy Key. This is an alternative to the token-based authentication and has the same effect as the personal access token, but it only provides access to a single repository. It is done as follows:
Generate an SSH keypair:
ssh-keygen -N "" -f deploy_key -C "github-actions"
Add the private key (generated file deploy_key) as an encryped secret, e.g. COMMIT_KEY to the GitHub project.
Add the public key (generated file deploy_key.pub) as a deploy key with write access to the GitHub project. Tick the Allow write access checkbox.
When checking out the source code in your workflow, add the SSH key:
- uses: actions/checkout#v3
with:
ssh-key: "${{secrets.COMMIT_KEY}}"

Related

GitHub Actions workflow do not respond to push event in other workflow

I have created a workflow that automatically merges branch A into branch B when branch A is pushed and a workflow that runs when branch B is pushed. However, the workflow does not run when branch B is pushed. Is this a GitHub specification? If so, I would like to know if there is documentation or an issue that clearly states this.
name: CI
on:
push:
branches: [ "A" ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Merge branch B
run: |
git fetch
git checkout B
git merge A
git push origin B
name: CI-2
on:
push:
branches: [ "B" ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Test
run: echo Hello
According to the official documentation (triggering a workflow from a workflow)
, this issue occurs because:
When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs. For example, 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.
To make it work:
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. To minimize your GitHub Actions usage costs, ensure that you don't create recursive or unintended workflow runs. For more information about creating a personal access token, see "Creating a personal access token." For more information about storing a personal access token as a secret, see "Creating and storing encrypted secrets."
If you're not familiar with the GITHUB_TOKEN concept and want to get more context about its usage, I suggest to check this section from the official documentation.

How to restrict your workflow to be only run by members of your organisation [Github-actions]

My org wants to use our CI tool on our public repos. Currently, anyone could just trigger the workflows and eat into our AWS accounts. Is there a way to set our workflows so they can only be run by our org members?
You should not need to change any default settings since only users with Write access to your repo should be able to trigger actions and by default, the public should not have direct write access.
Unfortunately at the moment there is no way to check if your organization contains the github.actor that triggered the workflow.
If you have GitHub Enterprise, you can create a protected environment where an approval is required before the workflow runs.
Technically you could check who is triggering the action against a list of usernames (shown below), but nothing stops someone with Write access from modifying the workflow yml to add themselves to the list of users who can trigger the workflow_dispatch action. Therefore this is not recommended.
if: contains('["kingthorin","lpoulter"]', github.actor)
For example:
name: Docker Build Action
on:
workflow_dispatch:
jobs:
build:
if: contains('["kingthorin","lpoulter"]', github.actor)
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v3
- name: Build the Docker image
run: docker build .

Auto commit from GitHub actions on push using "[skip ci]" in comment also skips workflow trigger on tag release

I have used the [skip ci] command as mentioned here to skip workflow runs in GitHub action, where I am doing an auto-commit after an image is built in CI aciton using PAT and this works wonderfully!
But as the commit comment contains the [skip ci] command and right after that if I create a new Tag release, the CI workflow is not triggered because of the [skip ci].
Is there any way I can exclude the [skip ci] for tag push event and keep it only for one of my branches where ci action runs?
Auto commit in GitHub action:
on: push
jobs:
ci:
runs-on: ubuntu-latest
steps:
- name: build and push image
- name: update image tag
- name: Commit changes
run: |
git config --global user.name 'abc'
git config --global user.email 'xyz#users.noreply.github.com'
git remote add origin https://github.com/${{ github.repository }}
git config --global push.default current
git remote set-url origin https://${{ secrets.PERSONAL_ACCESS_TOKEN }}#github.com/${{ github.repository }}
git commit -am "build: Image tag udpated [skip ci]"
git push
As you can see this action will run for all push events and the Commit changes step will make another commit using PAT but with [skip ci] in the comment so this same workflow is not triggered
again and it works.
But when I go to release a new tag with a new Release title and description, this action doesn't get triggered.
is there a way this can be avoided?
GitHub actions uses a special kind of security token which identifies itself as GitHub actions. It uses that fact to prevent actions from triggering more actions, potentially causing a cascade.
To bypass this protection you'll need to use different security token such as a Personal Access Token or an OAuth app token to perform the tag push action.
You can store that token as an action secret.
When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs. For example, 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.
https://docs.github.com/en/actions/security-guides/automatic-token-authentication#using-the-github_token-in-a-workflow
What you can do is to bail out as early as possible. To do so remove the [skip ci] token from the commit message and add your own, like [do-not-build], anything will do, really.
Then add a if: condition on the job that performs the build:
if: ${{ contains(github.event.commits[0].message, '[do-not-build]') }}
It will trigger the workflow, but the immediately skip the job.

Github action increment version on push to main

I would like to use a pure solution in a GitHub action to increment a version of the package. I don't want to use any existing actions from the GitHub marketplace such as "gh-action-bump-version
". I have this workflow, which will increase the version and create a tag.
name: Version Increment
on:
push:
branches:
- main
tags-ignore:
- v*
jobs:
version:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
with:
token: ${{ secrets.ACCESS_TOKEN }}
- run: git config user.email "$GITHUB_ACTOR#users.noreply.github.com"
- run: git config user.name "$GITHUB_ACTOR"
- run: npm version minor -m "v%s"
- run: VERSION=$(node -p "require('./package.json').version")
- run: git tag ${VERSION}
- run: git push origin --tags
- run: git push origin --follow-tags
It works, but it also cause a circular runs of the actions because of the last row. I know that I can use a custom message like "[RELEASE]" and put there a "if" condition and skip these commits. But my question is, is there any better solution to skip these commits from this action and do not use the "if" condition? Because the "tags-ignore" obviously doesn't work.
So I found several solutions. The first is that you can put "[skip actions]" to your commit message and that commit will skip any github action that should run within the commit. The second one is to use an address of the repository with access token.
This works pretty well for me:
name: Version Increment
on:
push:
branches:
- main
jobs:
version:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- run: git config user.email "$GITHUB_ACTOR#users.noreply.github.com"
- run: git config user.name "$GITHUB_ACTOR"
- run: npm version minor -m "v%s"
- run: VERSION=$(node -p "require('./package.json').version")
- run: git tag ${VERSION}
- run: git push "https://$GITHUB_ACTOR:${{ secrets.ACCESS_TOKEN }}#github.com/$GITHUB_REPOSITORY.git" --follow-tags
- run: git push "https://$GITHUB_ACTOR:${{ secrets.ACCESS_TOKEN }}#github.com/$GITHUB_REPOSITORY.git" --tags
Try using the built in GITHUB_TOKEN instead of your custom ACCESS_TOKEN. That should prevent the workflow from triggering another workflow.
From the docs (https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#triggering-a-workflow-from-a-workflow):
When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs. For example, 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.

Triggering a new workflow from another workflow?

Can I trigger a new workflow from another workflow?
I'm trying to run a workflow after the first workflow has pushed a new release and it seems to ignore it.
Found the answer here:
An action in a workflow run can't trigger a new workflow run. For example, if an action 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.
EDIT:
The quote above might be confusing. When I add a Personal Access Token (PAT) to the checkout action with repo permissions granted (and not repository's GITHUB_TOKEN), the following commands DO trigger other workflows:
- name: Checkout Repo
uses: actions/checkout#v2
with:
token: ${{ secrets.PAT_TOKEN }}
(In my case, running semnatic-release after this checkout, which creates a new release with a new tag - did trigger another workflow that runs only if a tag was created)
As described here, you can trigger another workflow using the workflow_run event.
For example we could think of two workflow definitions like this (the only prerequisite is, that both reside in the same repository - but I'am sure, there's also an event for other repos as well):
release.yml
name: CI release
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- name: Release artifact
run: ...
do-something-different.yml
name: Do anything after the release of the first workflow
on:
workflow_run:
workflows: ["CI release"]
types:
- completed
jobs:
notify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- name: Do something
run: ...
A crucial point here is that the name: CI release definition of the first yaml file must exactly match the workflow_run: workflows: ["CI release"] definition in the second yaml file. Another point is that this approach needs to be done on the default branch (which is mostly main or master) as the docs state:
Note: This event will only trigger a workflow run if the workflow file
is on the default branch.
If you don't want to use a general Personal Access Token (which has access to all of your repos), you can generate a dedicated SSH keypair for this purpose and add it to the repository as a Deploy Key. This is done as follows:
Generate an SSH keypair:
ssh-keygen -N "" -f deploy_key -C "github-actions"
Add the private key (generated file deploy_key) as an encryped secret, e.g. COMMIT_KEY to the GitHub project.
Add the public key (generated file deploy_key.pub) as a deploy key with write access to the GitHub project. Tick the Allow write access checkbox.
When checking out the source code in your workflow, add the SSH key:
- name: Checkout
uses: actions/checkout#v3
with:
ssh-key: "${{secrets.COMMIT_KEY}}"
Subsequent push actions in the same workflow will then trigger any configured GitHub workflow as if they were pushed manually.