Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GitHub Actions Not Respecting Trigger "On Create Tags" #1007

Closed
yousefcodes opened this issue Mar 11, 2021 · 9 comments
Closed

GitHub Actions Not Respecting Trigger "On Create Tags" #1007

yousefcodes opened this issue Mar 11, 2021 · 9 comments
Labels
bug Something isn't working

Comments

@yousefcodes
Copy link

Describe the bug
I have two github workflows, one that fires when pushing a branch to master. And another that fires only when a tag is created. However, I am itermittently seeing my tags workflow fire, even when I push a branch. This doesn't always happen, it only happens ocassionally and generally it follows the tag creation rule. However, this is our production github workflow, and we simply cannot have a branch push cause that action to fire. What gives?

Note, I had also created this issue here:
actions/runner-images#2898

To Reproduce
Steps to reproduce the behavior:

  1. Create a github actions workflow that fires on:
on:
  create:
    tags:
      - v*
  1. Push a branch up to the repo, don't create a tag. The workflow fires. This is itermittent and can't always be replicated. So I'm perplexed here. It happens often enough to be a problem.

Expected behavior
I would only expect this github action to fire when I create a tag named v1.0.0 or v1.0.1 or vAnything

Runner Version and Platform

Version of your runner?
This is happening live on GitHub.com not a local runner

OS of the machine running the runner? OSX/Windows/Linux/...

What's not working?

When a github action fires, the on part of the workflow.

Job Log Output

N/A

Runner and Worker's Diagnostic Logs

N/A

@yousefcodes
Copy link
Author

Not getting much traction on this issue, and thought I'd ask again!

@ChristopherHX
Copy link
Contributor

Hi,
If I understand the documentation correctly, it states that the branch and tag filter are only supported for push and pull_request events. Althought it isn't a yaml schema error, it seems to ignore branch and tag filter for all other events like create.

I made a simple workflow which only runs if you create a tag. All other create events are skipped.
At least it skips create branch events.

# This is a basic workflow to help you get started with Actions

name: prod-sample

# Controls when the action will run. 
on:
  # Triggers the workflow on push or pull request events but only for the main branch
  create:
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    if: ${{ startsWith(github.ref, 'refs/tags/v') }}
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2

      # Runs a single command using the runners shell
      - name: Run a one-line script
        run: echo Hello, world

I hope it helps :)

@hross hross closed this as completed Mar 30, 2021
@yousefcodes
Copy link
Author

This is wonderful, thank you! Worked as expected.

quantumfusion added a commit to pioneers/website that referenced this issue Jun 8, 2021
fix up the triggers to follow format as explained in this Issue: actions/runner#1007
AVSurfer123 added a commit to pioneers/website that referenced this issue Jun 19, 2021
* Create deploy action to make it easier to publish

* Fixes to the triggers

fix up the triggers to follow format as explained in this Issue: actions/runner#1007

* Rename main.yml to push-staging.yml

* Updated comments of workflow

Co-authored-by: Ashwin Vangipuram <[email protected]>
mudler added a commit to rancher/elemental-toolkit that referenced this issue Jul 6, 2021
It causes to fire events from the master pipeline also when we create
branches, as the create doesn't support filtering by tag.

See also: actions/runner#1007 on how to filter
by tag.

Signed-off-by: Ettore Di Giacinto <[email protected]>
mudler added a commit to rancher/elemental-toolkit that referenced this issue Jul 7, 2021
It causes to fire events from the master pipeline also when we create
branches, as the create doesn't support filtering by tag.

See also: actions/runner#1007 on how to filter
by tag.

Signed-off-by: Ettore Di Giacinto <[email protected]>
kstruempf added a commit to kstruempf/infrared that referenced this issue Nov 25, 2021
yeyus added a commit to yeyus/nhkeva that referenced this issue Jan 15, 2022
haveachin pushed a commit to haveachin/infrared that referenced this issue Feb 14, 2022
…104)

* Added github action for publishing docker images

* Added github action for publishing docker images

* Updated docker up repo name

* Upgraded to action build-push-action@v2

* Upgraded to action build-push-action@v2

* Correctly logging into github registry

* Added prepare step and setting imgage labels

* Pushing image to GHCR and Docker Hub

* Docker publish 'needs' tests to be run

* Only running docker pipeline on master

* ci: join docker build and go tests to one ci pipeline

* ci: move docker release to dedicated ci pipeline and triggering pipeline on new version tags

* docs: add hint for developers to use conventional commits

* fix(ci): never push images during build job

* fix(ci): change docker release trigger to run on creation of version tags

See actions/runner#1007

* fix(ci): change docker release trigger to run on creation and push of version tags

See actions/runner#1007 and https://github.com/docker/metadata-action#basic

* fix(ci): release branch is master not main

* fix(ci): run workflow anytime someone creates a branch or tag

See: https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows#create

* ci: use GitHubActions cache for docker images

* ci: move docker release to test-build-release.yml and use semver tag for images

* ci: setup buildx in release

* ci: push to GHCR on release add pre-release option for releases

* ci: push to GHCR on release add pre-release option for releases

* ci: add push to DuckerHub

* ci: no organization prefix for docker hub

* ci: move go release to test-build-release.yml so that artifacts can be included in GitHub release

* ci: fix go releaser version

* ci: keep dist and setting git tag before goreleaser

* ci: keep dist and setting git tag before goreleaser

* ci: provide commit ref for release instead of tag

* ci: use both tag and commit ref

* ci: remove git tag after go release

* ci: create release from conventional commit change loge before running gorelease

* ci: set tag before gorelease

* ci: delete release-go.yml

* ci: pre-release tag for github release

* ci: checking release_type for tagging as prerelease indicator

* ci: fix version of ncipollo/release-action

* ci: setup buildx in release

* ci: push to GHCR on release add pre-release option for releases

* ci: add push to DuckerHub

* ci: no organization prefix for docker hub

* ci: move go release to test-build-release.yml so that artifacts can be included in GitHub release

* ci: fix go releaser version

* ci: keep dist and setting git tag before goreleaser

* ci: keep dist and setting git tag before goreleaser

* ci: provide commit ref for release instead of tag

* ci: use both tag and commit ref

* ci: remove git tag after go release

* ci: create release from conventional commit change loge before running gorelease

* ci: set tag before gorelease

* ci: delete release-go.yml

* ci: pre-release tag for github release

* ci: checking release_type for tagging as prerelease indicator

* ci: fix version of ncipollo/release-action

* ci: also run test and build on PRs into 'pre-release'

Co-authored-by: Konstantin Strümpf <[email protected]>
haveachin pushed a commit to haveachin/infrared that referenced this issue Feb 20, 2022
* Added github action for publishing docker images

* Added github action for publishing docker images

* Updated docker up repo name

* Upgraded to action build-push-action@v2

* Upgraded to action build-push-action@v2

* Correctly logging into github registry

* Added prepare step and setting imgage labels

* Pushing image to GHCR and Docker Hub

* Docker publish 'needs' tests to be run

* Only running docker pipeline on master

* ci: join docker build and go tests to one ci pipeline

* ci: move docker release to dedicated ci pipeline and triggering pipeline on new version tags

* docs: add hint for developers to use conventional commits

* fix(ci): never push images during build job

* fix(ci): change docker release trigger to run on creation of version tags

See actions/runner#1007

* fix(ci): change docker release trigger to run on creation and push of version tags

See actions/runner#1007 and https://github.com/docker/metadata-action#basic

* fix(ci): release branch is master not main

* fix(ci): run workflow anytime someone creates a branch or tag

See: https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows#create

* ci: use GitHubActions cache for docker images

* ci: move docker release to test-build-release.yml and use semver tag for images

* ci: setup buildx in release

* ci: push to GHCR on release add pre-release option for releases

* ci: push to GHCR on release add pre-release option for releases

* ci: add push to DuckerHub

* ci: no organization prefix for docker hub

* ci: move go release to test-build-release.yml so that artifacts can be included in GitHub release

* ci: fix go releaser version

* ci: keep dist and setting git tag before goreleaser

* ci: keep dist and setting git tag before goreleaser

* ci: provide commit ref for release instead of tag

* ci: use both tag and commit ref

* ci: remove git tag after go release

* ci: create release from conventional commit change loge before running gorelease

* ci: set tag before gorelease

* ci: delete release-go.yml

* ci: pre-release tag for github release

* ci: checking release_type for tagging as prerelease indicator

* ci: fix version of ncipollo/release-action

* ci: setup buildx in release

* ci: push to GHCR on release add pre-release option for releases

* ci: add push to DuckerHub

* ci: no organization prefix for docker hub

* ci: move go release to test-build-release.yml so that artifacts can be included in GitHub release

* ci: fix go releaser version

* ci: keep dist and setting git tag before goreleaser

* ci: keep dist and setting git tag before goreleaser

* ci: provide commit ref for release instead of tag

* ci: use both tag and commit ref

* ci: remove git tag after go release

* ci: create release from conventional commit change loge before running gorelease

* ci: set tag before gorelease

* ci: delete release-go.yml

* ci: pre-release tag for github release

* ci: checking release_type for tagging as prerelease indicator

* ci: fix version of ncipollo/release-action

* ci: also run test and build on PRs into 'pre-release'

* docs: fix build badge in README.md

* chore: fix comment in pipeline

Co-authored-by: Konstantin Strümpf <[email protected]>
nicklasfrahm added a commit to nicklasfrahm/k3se that referenced this issue May 4, 2022
@monkut
Copy link

monkut commented Jul 18, 2022

It appears that this may perform the same desired result?

name: prod-sample

# Controls when the action will run. 
on:
  push:
    tag:
      - v*

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2

      # Runs a single command using the runners shell
      - name: Run a one-line script
        run: echo Hello, world

@KonradHoeffner
Copy link

I am not sure if that produces the same result when the tag is manually created using the GitHub web interface instead of being pushed.

MG-5 added a commit to netz39/Ordnungen that referenced this issue Nov 26, 2022
alex-f-k added a commit to gevamu/corda-payments-sdk that referenced this issue Dec 12, 2022
As per actions/runner#1007 issue, tags filter is available for push event, not create
alex-f-k added a commit to gevamu/corda-payments-sdk that referenced this issue Dec 12, 2022
* Do not run release workflow on PR create

As per actions/runner#1007 issue, tags filter is available for push event, not create
@Zeratoxx
Copy link

Zeratoxx commented Mar 2, 2024

I am not sure if that produces the same result when the tag is manually created using the GitHub web interface instead of being pushed.

@KonradHoeffner Nope, doesn't work afaik.

I am also kinda confused.. the workaround from @ChristopherHX with if: ${{ startsWith(github.ref, 'refs/tags/v') }} is not completely enough imo.

What about a tag called like validation, generally starting with a 'v'? This would also trigger the job with the mentioned if statement.

@ChristopherHX
Copy link
Contributor

I am also kinda confused.. the workaround from @ChristopherHX with if: ${{ startsWith(github.ref, 'refs/tags/v') }} is not completely enough imo.

In my point of view your requirements here are different, since the op post of this issue uses v*, which also includes validation

What about a tag called like validation, generally starting with a 'v'? This would also trigger the job with the mentioned if statement.

I expect you would come up with variadic, value, variable as well that would require glob/regex matching

I would say game over with action expressions, at this point you need to spawn a job and do calculations in your own script then feed the job outputs to the if condition... Obviously that cost at minimum 1min of included/paid minutes and time on each run.

What you could do additionally check if it includes a . so validation doesn't match without enumerating it, but it also doesn't really check the format...

if: startsWith(github.ref, 'refs/tags/v') && contains(github.ref, '.')

So refs/tags/validation.exploit would still match..

@Zeratoxx
Copy link

Zeratoxx commented Mar 4, 2024

@ChristopherHX at this point it would be more convenient to have the possibility of writing

create:
  tags:
    - 'v[0-9]+.[0-9]+.[0-9]+'

I mean, the backend code does already exist for push, am I right? 🤔 😅

@ChristopherHX
Copy link
Contributor

I mean, the backend code does already exist for push, am I right? 🤔 😅

Maybe, but I was never a GitHub Employee and have no insights for anything.
Usually GitHub People tell you nowaday to post feature requests to Community Discussions a bunch of them seem to gone stale.
I usually write about things already possible and not about missing features, since I use GitHub Actions Hosted Runner for free without paying anything.

I gone so far and rebuilt the backend of GitHub by forking this repository and yes my backend only warns you about unavailability of the feature in GitHub Actions and still applies it. However only self-hosted runners are possible and no free runners by GitHub including missing security features and so on. I'm using my backend locally with a fake GHES aka Gitea

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

6 participants