Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add old_tag Output to the README #314

Merged
merged 2 commits into from
Jun 26, 2024

Conversation

gabriel-stackhouse
Copy link
Contributor

@gabriel-stackhouse gabriel-stackhouse commented Apr 12, 2024

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
Copy link

eportet commented Jun 22, 2024

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.

.gitignore Outdated
@@ -0,0 +1 @@
.idea/
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you remove this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤷 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
Copy link
Collaborator

sbe-arg commented Jun 22, 2024

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

@gabriel-stackhouse
Copy link
Contributor Author

gabriel-stackhouse commented Jun 26, 2024

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
Copy link
Collaborator

sbe-arg commented Jun 26, 2024

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.

@sbe-arg sbe-arg merged commit 5b0f9e4 into anothrNick:master Jun 26, 2024
@gabriel-stackhouse gabriel-stackhouse deleted the old-tag-output branch June 26, 2024 20:54
@gabriel-stackhouse
Copy link
Contributor Author

@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
Copy link
Collaborator

sbe-arg commented Jun 26, 2024

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
Copy link
Owner

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
Copy link
Owner

anothrNick commented Jun 26, 2024

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
Copy link
Owner

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
Copy link
Collaborator

sbe-arg commented Jun 27, 2024

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

@gabriel-stackhouse
Copy link
Contributor Author

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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants