search

equinixmetal-archive / packngo

[Deprecated] A Golang client for the Equinix Metal API. (Packet is now Equinix Metal)
https://deploy.equinix.com/labs/equinix-sdk-go/
Other
79 stars 53 forks source link

Create a release GH workflow #250

Open displague opened 3 years ago

displague commented 3 years ago

In order to avoid situations like #249, GH workflows should be used to tag new releases.

The release workflow should take a semver version, update libraryVersion in packngo.go, and tag the release.

Moreover, the RELEASE.md steps should be followed in the GH workflow, and the RELEASE.md should be updated to tell maintainers to dispatch the GH workflow.

t0mk commented 3 years ago

They somehow do this in Linode:

https://github.com/linode/linodego/blob/master/.github/workflows/release-drafter.yml

displague commented 3 years ago

If we use release-drafter, we will need a job in that workflow that runs just before release-drafter to do the version bump.

While we are at it, we could change const libraryVersion in packngo.goto var Version in version.go, this will make it easier to replace in automation, make the variable available to users, and make the variable something we can change at build time if needed.

I was thinking that the version + release would be part of a dispatched action, with prompts. ("What version do you want to release?" "What commish (default: master)?".

If we have to push a tag to master manually for release-drafter to trigger, we'll be just as likely to forget to update the version stamp.

A simple solution might be to use version.go (as above) and have make release attempt to tag a release using the version from that file. If the tag already exists, make release would fail.

I think I still prefer an automated workflow, we can likely make it smarter and take hints about what version to deploy. Maybe we need to keep "v0.8.0-beta" (where 8 is +1 of the current release) in version.go. Automation can remove the beta on release and then increment the number on the commit that follows the release.

displague commented 3 years ago

Since #281, we don't need to update the version stored in version.go.

This means that tags can be applied at any time, using the GH UI. Release automation would be beneficial for drafting release notes. For this, we should consider workflows that parse well-formatted commit messages and perhaps try to enforce that commit format to some extent.