add in documenation: UNRELEASED and DRAFT_RELEASE do not work together

[treee111]

Why this issue?

I don't know how I came to that configration and if it worked earlier or not.
Lately I saw it not updating the latest release and it took me some time to figure out what causes this issue.
The errormessages, in my opinion, did not lead to the misconfiguration. That's why I want to inform you about that, if you have a place for that to be documented, feel free to do so!

Description

UNRELEASED: "update" together with DRAFT_RELEASE: true does not work after the first time.
It works the first time but seams that the created draft-release can not be changed by the action on the second and all further runs.

• non-working workflow configuration:

- name: Release
  uses: docker://antonyurchenko/git-release:latest
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    UNRELEASED: "update"
    ALLOW_EMPTY_CHANGELOG: true
    DRAFT_RELEASE: true

• working workflow configuration:

- name: Release
  uses: docker://antonyurchenko/git-release:latest
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    UNRELEASED: "update"
    ALLOW_EMPTY_CHANGELOG: true

Reference

• non-working workflow configuration:
  https://github.com/treee111/wahooMapsCreator/actions/runs/4098103949

• working workflow configuration:
  https://github.com/treee111/wahooMapsCreator/actions/runs/4098160692

• my PR to correct it in my repo:
  [DEV] enable Github action to update latest release treee111/wahooMapsCreator#178

[anton-yurchenko]

Hello @treee111, thanks for raising this issue.

According to the log from the failed execution, it seems that the execution crashed while trying to create an already existing latest tag:

WARNING precedent release not found
FATAL error creating latest tag: POST https://api.github.com/repos/treee111/wahooMapsCreator/git/refs: 422 Reference already exists []

Currently, git-release does not validate the latest tag existence and assumes it is absent when no release is found.

The PR fix must be a coincidence because DRAFT_RELEASE is not used within the action itself but passed as is to the GitHub API during a release creation call.

The latest tag was present without a release during a CI execution. You should be able to switch to the initial configuration with possible manual cleanup of tag and/or release.

P.S: I wil look into improving that in future releases

[treee111]

Hey @anton-yurchenko,
thanks for reaching out!

The latest tag was present without a release during a CI execution. You should be able to switch to the initial configuration with possible manual cleanup of tag and/or release.

I read the log as well and thought the same. That's why that particular code change was not obvious to work around that.
I tried deleting the release and tag manually via Github UI before running the action. Before creating this issue but also now.

These are my findings:
working workflow configuration from above:

1. delete release and tag via Github UI
2. let a commit with commitmessage "message 1" trigger the action
3. release and tag are created with the text "message 1"
4. let a commit with commitmessage "message 2" trigger the action
5. release and tag are updated with the text "message 2"

non-working workflow configuration from above:

1. delete release and tag via Github UI
2. let a commit with commitmessage "message 1" trigger the action
3. release and tag are created with the text "message 1"
4. let a commit with commitmessage "message 2" trigger the action
5. release and tag are NOT updated and text of both stay are still "message 1"

Does that come in hand with your answer?
As I have no other action creating the tag I think the Github API call of your action creates both the release and the tag. With the additional DRAFT_RELEASE passed to the Gibhub API, Github might not be able to update the release because it strugles with the tag.
The Github API creates both in the first run but then has struggle with the already existing tag in the second run as it seams?!

I understood the action as to update the latest release also if it already exists.
Is this valid or is this something false in the back of my mind?

Why I want to use this: I want to use it for a release-branch which should create a release with artifacts each time a commit is pushed to that branch.

[anton-yurchenko]

Hello @treee111,
This behavior was improved in v5.0.2.

Please reopen this issue or leave a comment if the problem persists.

P.S: I noticed you use the latest version in your flow. It is recommended to lock to a major version instead, like v5, and update using dependabot or equivalent