Support for multiple tags

[asangas]

It would be great if this action can support multiple tags. The use case is mainly for release management of actions and reusable workflows, where we would be creating a new tag as usual (v1.3.0), and also move the major version tag (v1) to point to the same Git ref.

This is following the official versioning recommendations:

• Create a release using semantic versioning. For more information, see "Creating releases."
• Move the major version tag (such as v1, v2) to point to the Git ref of the current release. For more information, see "Git basics - tagging."
• Introduce a new major version tag (v2) for changes that will break existing workflows. For example, changing an action's inputs would be a breaking change.

I feel that the cleanest way would be to expose a new optional input update_tag_name or update_tag_names to make a distinction with tag_name. (tag_name would attempt to create a new tag, while update_tag_name would create a new tag if it does not exist, or move if it exists).

I'm more than happy to work with you to refine this feature request, and raise a PR if accepted.

[sschuberth]

Personally, I feel that any write operations to the Git repository (like "updating" / "moving" a remote tag by deleting and recreating it) should be out of scope of this action.

[asangas]

@sschuberth a core functionality of this action is tagging, and isn't that a write operation already?

[sschuberth]

AFAIU it's not this action that tags, but the action gets trigger on a tag created / pushed by the user. And that's exactly how it should be, IMO.

[asangas]

That's not how I'm using the action, but after reading the source code again, I believe that I may be using the action in a way that's not designed.

This is an extract from my workflow:

     - name: Create Github Release 
        uses: softprops/action-gh-release@v1
        with:
          tag_name: ${{ steps.version.outputs.version }}
          token: ${{ secrets.GITHUB_TOKEN }}

The tag is not present by the time I invoke the action and it does get created with the release. I suspect that the GH API method that creates a release would create the tag too when the tag does not exist.

I'll do some testing tomorrow and confirm my theory. There could be a bug present in the logic that asserts whether the ref is a tag or not.