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.

[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:

[bmanth60]

Not sure if this is valuable, but since you already had the complete github workflow and you are using the ui for releases anyways, have you considered the release workflow event? https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#release

[bep]

Not sure if this is valuable, but since you already had the complete github workflow and you are using the ui for releases anyways, have you considered the release workflow event?

What exactly do you mean by this?

Edit in: OK, reading it again, I think I understand. GitHub emits a "release event" when I hit the "publish release" from the UI that we can use to start the package job. Yea, that could work. I will check.

[bep]

Drum roll .... https://github.com/gohugoio/hugo/pkgs/container/hugo/280590856?tag=v0.135.0 ... thanks to @bmanth60 for the tip that solved this.

[bep]

Now, if someone could contribute with some short documentation about how to use this image (I guess somewhere in https://github.com/gohugoio/hugoDocs), that would be appreciated.

[bmanth60]

Thanks bep! Thanks for interpreting!

[jmooring]

Now, if someone could contribute with some short documentation about how to use this image

To get started:
#12885

Docs issue:
gohugoio/hugoDocs#2727

[eallion]

I think we should need the latest tag and Docker Hub images.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.