-
Notifications
You must be signed in to change notification settings - Fork 44
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
chore: create and attach binaries on tag, release #91
chore: create and attach binaries on tag, release #91
Conversation
Note: due to the nature of how the version is generated in Chisel right now (parsing from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice. looks clean and aligned with Pebble's workflows.
Do you have an example of a successful run?
Wrt the lightweight tags: what if a release is created from a lightweight tag? wouldn't this try to attach the binaries to the wrong release?
This is the test release on my fork: https://github.com/rebornplusplus/chisel/releases/tag/v1.0.1 (Notice the attached tarballs)
So if a release is published with lightweight tags, v="$(git describe --always | sed -e 's/-/+git/;y/-/./' )" To allow lightweight tags to contribute to version determination, we will need to pass the |
Thanks for the details @rebornplusplus! Alright, so wrt the lightweight tags, that seems to be what we also do in Pebble -> https://github.com/canonical/pebble/blob/f5938105cb2611c7753f63beff5c71373ff0612b/cmd/mkversion.sh#L46 Unless you see a good reason why we should avoid releases that are based on lightweight tags, I think it would be safer to just add |
Sounds good. I have updated it in c272db4. Please take another look. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
great, thanks ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One comment that could make things a little easier to read. Let me know, this is pretty much ready to go.
Create binaries on push, tag creation and when a release has been published. Create an archive with the binary, and attach it to the release if a release is published. In all cases, attach the archive in the workflow run as an artifact. The actions/checkout@v3 action overwrites annonated tag with lightweight tags breaking ``git describe``. See [1], [2]. This commit adds a workaround to restore the latest tag to it's original state. References: - [1] actions/checkout#882 - [2] actions/checkout#290
c272db4
to
962061d
Compare
Requires #90.
(This PR includes commit 3e4ec0b from #90.)
Create binaries on push, tag creation and when a release has been published. Create an archive with the binary, and attach it to the release if a release is published. Attach the archive in the workflow run as an artifact in all cases.
The actions/checkout@v3 action overwrites annotated tag with lightweight tags breaking
git describe
. See [1], [2]. This commit adds a workaround to restore the latest tag to it's original state.References: