Is it possible to update existing release?

[ravgeetdhillon]

I have created a release using

- name: Create Release
  uses: ncipollo/release-action@v1
  with:
    name: ${{ env.next_version }}
    tag: ${{ env.next_version }}
    commit: master
    allowUpdates: true
    prerelease: false
    draft: false
    token: ${{ secrets.GITHUB_TOKEN }}

Let us suppose that it created a tag and release for 2.0.0.

Now next time when I run my workflow I want to update this 2.0.0 release and create a new one as well e.g. 2.0.1. How do I perform this step? I have performed the following operation but it gave me:

Error 422: Validation Failed: {"resource":"Release","code":"already_exists","field":"tag_name"} Errors: - Release already exists.

This is the workflow which I am trying to run.

# create a new release
- name: Create Release
  uses: ncipollo/release-action@v1
  with:
    name: ${{ env.next_version }}
    tag: ${{ env.next_version }}
    commit: master
    allowUpdates: true
    prerelease: false
    draft: false
    token: ${{ secrets.GITHUB_TOKEN }}

# update the existing one
- name: Create Release
  uses: ncipollo/release-action@v1
  with:
    tag: ${{ env.major_version }}
    commit: master
    token: ${{ secrets.GITHUB_TOKEN }}

[ravgeetdhillon]

My use case is related to Github Actions. I have a Github Action and I released its version 1.0.0. I want all my users to use this version. Now I decide to add a new feature or a fix and release a new version 1.0.1. But my existing users won't be able to use it as they are using 1.0.0.

So what I want to do is whenever a new release is made I want to update the base version which in this case is 1.0.0. However, when a breaking change would be made, it will not update 1.0.0 rather create 2.0.0. Any subsequent features or fixes will then update 2.0.0.

I hope you get an idea.

[ncipollo]

Hi @ravgeetdhillon ,
If I understand correctly it sounds like you would like your workflow to update the commit your tag is pointing to in some cases. Unfortunately this is outside the scope of the action. The action can create a tag but that is completely done via the github releases API. That API allows you to create a tag as a convenience when you are creating a release. As far as I know it doesn't really allow you to update that tag after it's been created.

Check out the documentation for that call: https://docs.github.com/en/rest/reference/repos#create-a-release . Note the description of target_commitish:

Unused if the Git tag already exists

In other words, the API will not update the commit the tag is pointing to if that tag already exists.

If you want to automate tag management via a workflow I think your best bet would be to have a step which leans on a simple bash script which does something like git checkout main;git tag -f 1.0.0;git push -f origin 1.0.0.

All that being said I would actually advice against automating tag management in this use case. As you alluded to in your second comment, human decision making is required in order to determine if a change set constitutes a a major, minor or patch release. If you attempted to automate this, you could end up unintentionally making a breaking change which gets synced to v1.0.0. In my experience, it's better to set the action up so it runs when a tag is pushed, then you can choose when you want to update v1.0.0 manually. Here's an example repo which is setup to generate a release whenever a tag is created or updated - https://github.com/ncipollo/actions-playground/blob/0.0.71/.github/workflows/tag.yml

Also, on a semi-related note: I would avoid updating a tag like 1.0.0 after it's released. Typically once a semantically versioned release is published it's more or less static. Changing a release like that after it's been published can erode the trust of your users (this minimally creates security & stability concerns). I'd recommend having a tag which provides some indication that it's dynamic and not a stable, semantic release (ex - v1, nightly).

[ravgeetdhillon]

@ncipollo ,
I think your last para makes sense and it is exactly what I am looking for. I want to publish a version like v1 and then update it regularly on new releases.

I really want to ask you what is your workflow for maintaining this action. I can see that you have made many releases but you ask your users to use v1. So my question is when you create a new release, how do you update the v1?

[ncipollo]

Hi @ravgeetdhillon,
I more or less follow the recommendations here: https://github.com/actions/toolkit/blob/master/docs/action-versioning.md#recommendations

1. Tag the new release: git tag 1.0.1
2. Push the new release git push origin 1.0.1
3. Update the dynamic tag: git tag -f v1
4. Push the dynamic tag: git push -f origin 1.0.1

[ravgeetdhillon]

Worked like a charm. Thanks @ncipollo .