Add old_tag Output to the README

[gabriel-stackhouse]

Summary of changes

I use this Action as a step in my own larger workflow, and I needed a reference to the old tag (pre-version bump) for some steps further along the process. Digging into the code, I realized that the output is already being set - it's just not documented in the README. So let's add that in so others know of that output as well.

Breaking Changes

NO

How changes have been tested

No code changes have been made - simply a README update.

List any unknowns

N/A

[eportet]

This should get merged! I had always used the tag value instead but now I realize it's the old_tag that I wanted to use.

[sbe-arg]

Can you remove this?

[gabriel-stackhouse]

🤷 Sure. Though it's useful to have in there for those of us who use JetBrains IDEs, so as to not include those files in the repository.

[sbe-arg]

We can merge it for documentation purposes but we still cannot create releases.

[gabriel-stackhouse]

We can merge it for documentation purposes but we still cannot create releases.

@sbe-arg Out of curiosity, why is that? Having frequent published releases for GitHub Actions makes it easy for users to make use of the most up-to-date version in their workflows. As it stands, there have been many recent updates, yet most users are using a version over one year old (1.67.0).

For others, I'm referencing my other recent PR: #317.

[sbe-arg]

There is a problem with this repo where we cannot use this repo own action in local mode to do the releases of this same repo. Something that runs on the tests as well.

We have no clue why.
If you read the history of the last few opened and closed prs by @anothrNick you will see.

Example #311

Also as now we won't use another action to release the code of a third party action that handles releases if this action cannot run self releases its own repo then.
It defeats its on purpose and lack of trust to users to introduce another dependency.

[gabriel-stackhouse]

@sbe-arg If you don't want to use a third party action to publish releases (which is understandable), you could also reference the GitHub API directly:

https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28#create-a-release

Or use GitHub CLI, which is automatically installed in all Ubuntu images in GitHub Actions:

https://cli.github.com/manual/gh_release_create

I'd be happy to put together a PR using one of those, which would work just as well and wouldn't introduce a 3rd party dependency.

[sbe-arg]

It is the literal reason why I made this other action https://github.com/sbe-arg/simple-tags-and-releases

This repo can only be released using its own action. Not a third party action. (it does not look good offering an action that does releases but cannot release itself consistently, not a good luck IMO)
The theory is the @anothrNick fixed this in the last few pr juggling. But I have 0 time to test if it works. if we merge something and breaks it might remain broken. There are no active contributors or maintainers at this moment if you want to take on. Have a chat with Nick. 🤷

#238

[anothrNick]

This action was never intended to create releases, just tag commits. I've just done manual releases in the past. Happy to create a new release with the latest version.

[anothrNick]

Yea I'm a bit confused here @sbe-arg. This action has a single purpose; to tag a commit semantically. I would argue that it's better to have another action create releases based on the new commit/tag, if desired. That way workflows are nice and modular.

There are also numerous actions to create releases with notes, something I don't think this action should compete with. I think there's some confusion here between tags and releases. My most recent change is meant to fix tagging on PRs submitted from forks of this repo (a bug in the workflow definition, not in this action's code).

[anothrNick]

Huh, I guess I take that back. Auto release has been working - https://github.com/anothrNick/github-tag-action/releases

They're draft by default.

[sbe-arg]

We use the marvin pinto releases project wich is also deprecated.

[gabriel-stackhouse]

I would argue that it's better to have another action create releases based on the new commit/tag, if desired. That way workflows are nice and modular.

@anothrNick , just to be clear, I completely agree with you here. I'm not suggesting you make release creation a part of this Action specifically; there are plenty of other Actions out there that already do this quite well.

That said, there's nothing stopping from you adding a release step to the workflow of this repository to keep things visible and up-to-date for your users. In fact, I think it'd offer a great example of how this Action can be used in their own larger workflows.

[anothrNick]

Agreed @gabriel-stackhouse. I re-opened #317 to update our workflow, thanks for that.

@sbe-arg I'd like to hear your thoughts here, however. Perhaps there was a contribution working towards adding release support to this action and I missed it, as I'm not very active with this project.