Repository: gohugoio/hugo (language: go)

Issue:
The new Docker package workflow not triggered by release tags
https://github.com/gohugoio/hugo/blob/caa90e6a12061893c01bea77030f1e90970cc25c/.github/workflows/image.yml#L6

Not sure what's wrong.


Discussion / hints:
/ccn @morremeyer 
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?
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.

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.
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.
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
@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 ...
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.

```diff
on:
  push:
    tags:
      - "*"
-    paths:
-      - Dockerfile
-      - .github/workflows/image.yml
 ```
>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.

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 ...
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.
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.
@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.
@morremeyer I know, I forgot that it is the case for the private registries/repositories only. **Sorry for misinformation**
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.
Allow me to interject, I guess this may because of the **release** [commit](https://github.com/gohugoio/hugo/commit/3fd26c70dff5934ec1802b9563530130ed1bca75) 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/
>[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`.

> 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](https://github.com/razonyang/github-workflows-testing/blob/main/.github/workflows/events-push.yml) will be skipped if commit message contains `[ci skip]`.

[Commits](https://github.com/razonyang/github-workflows-testing/commits/main/?since=2024-08-18&until=2024-08-18)

![image](https://github.com/user-attachments/assets/be868006-9a1e-4a67-b5a4-a9e162f8f004)

[Actions](https://github.com/razonyang/github-workflows-testing/actions/workflows/events-push.yml)

![image](https://github.com/user-attachments/assets/b2054d8d-8362-4cb5-8e69-15443f05f852)

I tried to fix this, but had to revert, see 73d32e7737082118a48adb8db3ff1ed7407f4d3f

If someone knows (no guessing, please) how to set this up in CircleCI, a PR is welcome...

Fix patch:
diff --git a/.circleci/config.yml b/.circleci/config.yml
index 0ff9559365e..3093b28d43d 100644
--- a/.circleci/config.yml
+++ b/.circleci/config.yml
@@ -96,6 +96,15 @@ jobs:
 workflows:
   version: 2
   release:
+      when:
+        and:
+          - matches:
+              pattern: "^release-"
+              value: << pipeline.git.branch >>
+          - not:
+              matches:
+                pattern: "NOCIRCLECI"
+                value: << pipeline.trigger_parameters.github_app.commit_message >>
       jobs:  
         - prepare_release:
             filters:
diff --git a/releaser/releaser.go b/releaser/releaser.go
index f2244842ad3..1cc8413e90f 100644
--- a/releaser/releaser.go
+++ b/releaser/releaser.go
@@ -101,7 +101,8 @@ func (r *ReleaseHandler) Run() error {
 			return err
 		}
 
-		if _, err := r.git("commit", "-a", "-m", fmt.Sprintf("%s Bump versions for release of %s\n\n[ci skip]", commitPrefix, newVersion)); err != nil {
+		// About NOCIRCLECI, see issue #12753.
+		if _, err := r.git("commit", "-a", "-m", fmt.Sprintf("%s Bump versions for release of %s\n\nNOCIRCLECI", commitPrefix, newVersion)); err != nil {
 			return err
 		}
 


Test patch: