The new Docker package workflow not triggered by release tags

[bep]

hugo/.github/workflows/image.yml

Line 6 in caa90e6

- "*"

Not sure what's wrong.

[bep]

/ccn @morremeyer

[bep]

I'm guessing, but

• the tags gets created by the "publish button" on a new release, so I guess technically not a push ... but that would be really strange.
• or the "*" does not match; is it ... regexp?

[morremeyer]

The tag is still pushed, that is fine, and the "*" matches:

The branches, branches-ignore, tags, and tags-ignore keywords accept glob patterns that use characters like *, **, +, ?, ! and others to match more than one branch or tag name

from: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onpushbranchestagsbranches-ignoretags-ignore

But, the on I proposed would only run when the tag contains changes to the Dockerfile or the workflow file, which it never does since it always contains only the version bump.

[bep]

I have tested here https://github.com/bep/githubactionstest ... and the pattern we already have is working fine there, so I'm guessing it must be a glitch ... I'm adding the master branch to the on filter, which I think makes sense, but other than that ... who knows.

[bep]

Nope, the tags does not trigger the build, and I have no idea why. I have tested all variations fine on https://github.com/bep/githubactionstest/actions ... I don't see why this should behave differently.

[nikaro]

Just passing by as i skimmed the release notes and saw this, so i did not dig to much in your processes, but i've already stumbled on this when the tag was automatically created by another workflow.

When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN, with the exception of workflow_dispatch and repository_dispatch, will not create a new workflow run.
— https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/triggering-a-workflow#triggering-a-workflow-from-a-workflow

[bep]

@nikaro yea, I read that, too -- the thing is, the release tags in Hugo gets created by the "publish" button in the UI, but it's certainly some similar magic, question is what ...

[nikaro]

Could it be the paths filtering? As far as i know both conditions (tags and paths) must be satisfied for the workflow to be triggered. And as you will likely want to build an image on each new tag it does not seem useful anyway.

on:
  push:
    tags:
      - "*"
-    paths:
-      - Dockerfile
-      - .github/workflows/image.yml

[bep]

Could it be the paths filtering?

According to the docs and my tests (https://github.com/bep/githubactionstest/actions); no.

But it's a little hard to test this ... I don't want to create dummy releases, and I suspect other tags pushed from the console would behave differently.

[bep]

OK, I just pushed this tag to master:

https://github.com/gohugoio/hugo/releases/tag/testbuild1

Which did not trigger a package build, which I guess is great news as it means we can test it without releasing ...

[bep]

OK, so reducing it to this seems to work:

on:
  push:
    tags:
      - "*"

Mysterious ... Oh, well. I can add a workflow_dispatch so we can start it manually if we want to test it, I guess ... For now.

[bep]

OK, the release I just did, sadly did not trigger a build. OK, I don't understand this and I currently don't have more time to spare on this.

[morremeyer]

@webgtx I don't know where you got that information, but it is wrong.

See e.g. https://github.com/community-tooling/oci-images/blob/1aff6765f666244213f4aa3cfca4b578c104c06a/.github/workflows/build.yml, where we use the GITHUB_TOKEN without any issues.

This is what the permissions key is for, to set the appropriate permissions.

[webgtx]

@morremeyer I know, I forgot that it is the case for the private registries/repositories only. Sorry for misinformation

[bep]

This smells like a GitHub bug, but my current theory and workaround is:

• We create the release tag on a release branch.
• Then we merge the release branch into master.

This sounds a little off, but it could be that GitHub drops tags that's not reachable from the main branch ... And I guess I can try to switch the order of the 2 above.

[razonyang]

Allow me to interject, I guess this may because of the release commit contains [ci skip], so the Docker workflow was skipped.

If any commit message in your push or the HEAD commit of your PR contains the strings [skip ci], [ci skip], [no ci], [skip actions], or [actions skip] workflows triggered on the push or pull_request events will be skipped. ---- https://github.blog/changelog/2021-02-08-github-actions-skip-pull-request-and-push-workflows-with-skip-ci/

[bep]

[ci skip], so the Docker workflow was skipped.

OK, that may be it, but that [ci skip] is there for a reason (to stop triggering another release build). There may be a ways to work around that, but that will need to wait.

But this smells like a GitHub actions bug; the [ci skip] is on the commit and not the tag.

[razonyang]

But this smells like a GitHub actions bug; the [ci skip] is on the commit and not the tag.

Not sure, but a tag is tagged on a particular commit, it seems make sense.

I also made some tests, I created three commits (versions), and tagged each commit (v0.1.0, v0.2.0 and v0.3.0), the result is that the tag trigger workflow will be skipped if commit message contains [ci skip].

Commits

Actions

[bep]

I tried to fix this, but had to revert, see 73d32e7

If someone knows (no guessing, please) how to set this up in CircleCI, a PR is welcome...

[bep]

I have done some further experiments (no luck) here: https://github.com/bep/circlecitest

I'm putting this work on pause myself, but I welcome tips/prs in the above repo. The goal is to control the when by commit message content.

[bep]

OK, so @razonyang has come up with a circle CI setup that gets us around this issue; I will set it up in Hugo early the coming week.

[bep]

Unfortunately my new and promising attempt to update the Circleci build for this (repeatedly) failed with a cryptic error: