Github actions workflow not triggering with tag push

I have a workflow with 2 actions. The first action is triggered when a push is made to the branch and pushes new git tag and the second action is triggered when after a new tag is pushed. However, the second action is not triggering lately even though the tags are being created and pushed into git tags by the first action. Anyone else facing the same issue?

I am using the tag based build as below: also used create event. Nothing seems to work

on:
  push:
    tags:
      - '*'
2 Likes

Do you have two workflows, one with an action to push new tags and the other be triggered by tag creation ? Which token do you use in the first action to create new tag?

There is a limitation of workflow: An action in a workflow run can’t trigger a new workflow run.

When you use GITHUB_TOKEN in your actions, all of the interactions with the repository are on behalf of the Github-actions bot. The operations act by Github-actions bot cannot trigger a new workflow run.

You can go to releases page to see the user who released a release.

I would suggest you use your own PAT when creating tags. You can store your PAT in secrets and use

${{ secrets.PATNAME } in your actions.

env:

   GITHUB_TOKEN: ${{ secrets. PATNAME }}

https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets

6 Likes

Thanks a ton! It worked…

Is there any possibility of this changing? Adding a PAT to every repo in our organisation is not a good option for two reasons:

* We would have to update every single repo anytime we need to roll the token.

* If we create a user specifically for this kind of task then we have to pay for an extra seat.

18 Likes

Is this still a known problem? I’ve got something similar going on, where one action creates a development release tag, and a second action creates packaged executables for releases, but the second action is never run. My releases/tags do have myself as the author, and not the bot.

It’s still by design, see Using the GITHUB_TOKEN in a workflow:

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.

Note that this is not about who is the commit or tag author, but how the push is authorized.

Thanks for the reply! I should have been a bit clearer. I do use a custom authentication token for the push to push the tag, say master-dev (see the workflow at betty/tag-dev.yml at d86e925add3fba3bb46837ed1065a226fe09b914 · bartfeenstra/betty · GitHub), but only when I push master-dev from my local machine, does the release package workflow run (betty/publish-windows-exe.yml at d86e925add3fba3bb46837ed1065a226fe09b914 · bartfeenstra/betty · GitHub). I’ve been staring at this for a while, but am unsure what’s missing.

A such limitation is ‘by design’ ?
We are setting up a manual workflow for our releases to avoid manual mistakes.
How this workflow is able to schedule builds, packagings and deployments on the tags and branches it creates ?
Using a personal token is not an acceptable answer as personal token are not scope to an organisation. I don’t want to setup a token on an organisation that is able to do actions on another one.
Created technical accounts to do git push instead of the GIT_TOKEN is a security breach and a mess in term of maintenance.

Deploy Keys offer the solution you’re looking for: they’re repository scoped! I’ve written a complete blog post called Trigger another GitHub Workflow — without using a Personal Access Token but in summary:

  1. Create a Deploy Key
  2. Add the private key as a Secret in your repository, e.g: COMMIT_KEY
  3. Authenticate Git operations using the Deploy Key, e.g:
- uses: actions/checkout@v2
  with:
    ssh-key: "${{ secrets.COMMIT_KEY }}"

Any Git operation performed by your Workflow – e.g: a Push – will trigger Workflows, because GitHub does not restrict Deploy Keys.

3 Likes

Thanks, it works.
Need to manage a lot of keys :frowning: