Cannot create a release

[mquinzin]

HI, I'm using your app since 2 years and it works perfectly. (v1.1.2)
Today I copied my github repo into a new one to do some tests, and I have a weird message:

! [remote rejected] latest-20240704 -> latest-20240704 refusing to allow a GitHub App to create or update workflow .github/workflows/xxx.ymlwithoutworkflows permission Error: ❌ Command 'git push --force origin latest-20240704' returned with non-zero exit code!

The CI is the same, I use token: ${{ secrets.GITHUB_TOKEN }}
I tried with a personal token with all permissions, same thing.

Is there something I had configured on my first repot that I have forgotten to do on the new one ?
I'm sorry but I'm completely stuck.

[mini-bomba]

Hm, did the commit that triggered this workflow change a workflow file?

[mquinzin]

Yes since I'm testing and mofifying my CI

[mini-bomba]

From the error message this appears to be the issue. I don't remember this happening previously, it's possible it's a recent-ish change on the github side.
I have two possible quick solutions in mind, you can either:

• manually tag the current commit with the desired label and push it to github, then try running the workflow again (and repeat this every time you change a workflow)
• or you can try giving the workflow (or action) a write workflows permission as suggested by the error message from github (this may or may not be a security risk)

[mquinzin]

This is weird, because I'm pretty sure that in my working repo I have already modified the workflow and had not trouble with the action.
Anyway, so if I commit and push something that concern anything but the workflow it should work, let's try

[mquinzin]

Same thing, same error.

In fact I have a difference with my working repo.

In this new CI I don't checkout and release the current commit, but I work with a tag.

` - name: Checkout git sources

    uses: actions/checkout@v4

    with:

      clean: 'false'

      lfs: 'true'

      ref: ${{ env.LAST_STABLE_TAG_NAME }}

...

  - name: Release the new binaries
  - 
    uses: docker://ghcr.io/mini-bomba/create-github-release:v1.1.2

    with:

      token: ${{ secrets.GITHUB_TOKEN }}

      target_commit: ${{ env.LAST_STABLE_COMMIT }}

...
`
Could it come from there ?
I'll continue my tests tomorrow, thx for hep

[mini-bomba]

This action was created with triggering on pushes to a branch in mind, to create/update the tag and attach release files to that. Just modifying the release files without updating the commit the tag points to, or creating a release on an existing tag wasn't really something I had thought of, although adding the feature would likely be as simple as adding a few if statements.

Let me know if you indeed are trying to create a release on an existing tag - if so, then I can add the feature to support this.

[mquinzin]

This action was created with triggering on pushes to a branch in mind, to create/update the tag and attach release files to that. Just modifying the release files without updating the commit the tag points to, or creating a release on an existing tag wasn't really something I had thought of, although adding the feature would likely be as simple as adding a few if statements.

Let me know if you indeed are trying to create a release on an existing tag - if so, then I can add the feature to support this.

So, what is the option "target_commit" for ? In my understanding it was to set the commit id we want to point on, to create the release.
What I want to do is:
Manual set a tag last-stable pointing on a wanted commit.
Manually run a worklow that:

• checkout files for last-stable
• build & QA
• create a release with your action to push the created binaires and the files (as sources) related to my tag last-stable

[mini-bomba]

I don't exactly remember what the usecase for target_commit was, because the last time I've actually touched the code of this action was 2 years ago.

Whether you set the target_commit option or not, the script assumes the tag is not in the correct place yet and will try to modify the tag.
This assumption is incorrect in your case, as you've already manually set the tag to point to the correct commit.

I'll add the necessary checks to skip the tag modification if the script detects that the tag is already in the correct place, or if a new option is passed in.

[mquinzin]

Ok thank you very much, that would be very nice.

[mini-bomba]

I've added this in the just-published release v1.2.0.

You can now set the new skip_tag_creation option to true to prevent the action from attempting to modify the tag, instead using it as-is.
It should also work without any option changes, but will generate a warning.

Let me know if this has resolved your issue.

[mquinzin]

Thank you for you work, but it seems something is not OK, here is my test.

I call the action with:
uses: docker://ghcr.io/mini-bomba/create-github-release:v1.2.0
skip_tag_creation: true
target_commit: last-stable

I created several commit inserting lines in a file: aaa, bbb, ccc ...
Here is my gitlog of the repo:

Here is the gitlog of the worksapce used when your action is called (it points on last-stable as wanted):

So the creation went OK, but if I download the "Source code (zip)", I expect to find ddd in my file (since the last-stable tag points on it).
But I find fff in my file, that is weird because that comes neither from the current commit id (should be ggg) nor from the last-stable tag (should be ddd)

I don't understand.
Thx for your help.

[mini-bomba]

The target_commit option is completely ignored when skip_tag_creation is true. What matters is the tag option.

These "Source code" attachments are autogenerated by github, the action does not and cannot modify these.
Unless the tag is pointing to the wrong commit, this sounds like a github issue.

[mquinzin]

Ok sorry for the misunderstanding.
So the only one thing I have it to use v1.2.0 (without the skip_tag creation).
Everything seems OK so, the source code has been generated from the tag last-stable.
Many thanks.

[mini-bomba]

Thanks