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
bug: git tag: uses first tag that matches commit and not the latest #255
Comments
@lrstanley As you can see in the logs, the action actually found the right tag based on
But yes GoReleaser itself found the previous one:
Maybe translate the logic here to GoReleaser? WDYT @caarlos0?: Lines 12 to 31 in d19982d
|
Sounds good @crazy-max, want to open a pr or should I? |
@caarlos0 Hum actually I could set |
Hmm that might work as well |
## Motivation Goreleaser is not interpreting the correct tag, here's a related issue: goreleaser/goreleaser-action#255. The workaround is to set an env var `GORELEASER_CURRENT_TAG`. I also sneaked some minor changes to how acceptance tests are run so that we can provide it with ref to run against.
This is technically more related to goreleaser itself and not the action, however I think reporting it under the action repo still makes sense due to the type of bug.
I've got a workflow setup so when I push to any tag, it will automatically build and release it on GitHub:
https://github.com/lrstanley/links/blob/master/.github/workflows/release.yml
However, there is a problem where if I tag the same commit twice (i.e. triggering it to rebuild the code with a different Go version as an example), it still only picks the FIRST tag that relates to that commit.
As you can see in the following build output (I've since deleted the new v0.5.3 tag, but this log still exists), you can see GitHub sees the new tag, and it clones the git repository down with that tag, however goreleaser is still using the v0.5.2 tag:
https://github.com/lrstanley/links/runs/1392634281?check_suite_focus=true
That is likely due to goreleaser using the following command (or something similar):
However, we can see with the following command, that two tags actually relate to the commit:
You may wonder why I am even retagging the same commit. This is because there isn't a super easy way of automating goreleaser to rebuild, retag, and release the same code, but with a newer version of Go, at least with GitHub actions today. If the code doesn't need to be changed, there isn't really any kind of commit that needs to happen, to qualify for goreleaser to pick it up.
actions/checkout
is providing? Or, is there a way goreleaser can notice thatactions/checkout
checked out a specific tag, and use that tag?Logs from
actions/checkout
...:Logs from
goreleaser
:The text was updated successfully, but these errors were encountered: