feat: Transparent release process #480
Conversation
bonddim
commented
Jul 3, 2023
bonddim
commented
- Added goreleaser config
- Add release workflow
|
@bonddim Thanks! Just wondering, how did you test this?! If you've already run goreleaser using this config on your repo, I'd love it if you could share it for review 🙏 |
There was a problem hiding this comment.
Thank you for your contribution!
I wanted to introduce MVP of release automation and do incremental enhancements on top of that, and #517 is my first attempt.
I've commented on this PR to note differences. If you are still around, I'd love your confirmation and feedback!
| archives: | ||
| - format: tgz | ||
| name_template: '{{ .ProjectName }}-{{ tolower .Os }}-{{ .Arch }}' | ||
| wrap_in_directory: diff |
There was a problem hiding this comment.
I think we don't need this wrapping, because our installation script doesn't expect it.
There was a problem hiding this comment.
All files in latest release are wrapped into diff directory, and installation script uses it :
Line 126 in f5cb542
There was a problem hiding this comment.
You are absolutely correct @bonddim! Thank you very much for the confirmation and the correction. You saved the day!
| snapshot: | ||
| name_template: '{{ incpatch .Version }}-{{ .ShortCommit }}' | ||
|
|
||
| changelog: |
There was a problem hiding this comment.
I missed this in my PR so let me check later!
There was a problem hiding this comment.
Doesn't required for releases, but I like this snapshot versioning
|
|
||
| archives: | ||
| - format: tgz | ||
| name_template: '{{ .ProjectName }}-{{ tolower .Os }}-{{ .Arch }}' |
There was a problem hiding this comment.
It turned out we had to use macos instead of darwin in the archive name.
There was a problem hiding this comment.
This is correct - I missed this.
| - darwin_arm64 | ||
| - linux_386 | ||
| - linux_amd64 | ||
| - linux_arm |
There was a problem hiding this comment.
If I'm not missing anything, we can safely omit 386, arm, ppc64le and s390x "yet" as we don't publish binaries for those archs today.
There was a problem hiding this comment.
Just included all architectures supported by Helm.
Yes, its safe to omit them, but why to not include them now?
| @@ -8,4 +8,3 @@ fi | |||
|
|
|||
| git tag $1 | |||
| git push origin $1 | |||
| gh release create $1 --draft --generate-notes --title "$1" release/*.tgz | |||
There was a problem hiding this comment.
Good catch! Today, the release process looks like the below:
- Add a commit that updates plugin.yaml to have a new version
- Run this release.sh
After this and #517, the process would look like:
- Add a commit that updates plugin.yaml to have a new version
- Run this script, or create a semver tag along with the release on the GitHub web UI
- The workflow gets triggered on GHA. goreleaser does the rest.
I guess we'd rather prefer the below:
- Add a commit that updates plugin.yaml to have a new version
- A GHA workflow reads the new plugin.yaml version value and tags the commit with the version
- The release workflow gets triggered and goreleaser does the rest.
Maybe we can modify this release.sh to do the second bullet point?
Basically, we can deduce $1 here from plugin.yml by reading the version field using eg. yq? 🤔
* Automate releases using GHA To publish a release, we currently have to run `make docker-run-release` locally after tagging a release, which is not a huge effort but a bit cumbersome, because we do it only a few times a year and that is long enough to lose my memory :) Starting this change, we use a GHA workflow to automatically build and publish binaries whenever a new semver tag is created, so that we do not need to run `make` anymore. * Applies bonddim's suggestion. Thx! * We do have to wrap files in the diff dir. See #480 (comment)
