fix&bring the CI update to date, document the release workflow#53
fix&bring the CI update to date, document the release workflow#53danielpodwysocki-gini merged 6 commits intomasterfrom
Conversation
411662b to
3f778e8
Compare
3f778e8 to
6095bac
Compare
950358d to
f8104e8
Compare
also updates syntax to match our new goreleaser version
f8104e8 to
d21155b
Compare
There was a problem hiding this comment.
When changing the release process, I would also suggest to include release names of the shape 0.0.0-rc.0. We do the same for fedora-coreos-config to test release candidates on feature branches, before merging them and creating a final release (without -rc.0). That can be used as blueprint also for other repos such as the ops-infra-operator
Do you plan to merge the dependabot PRs for version upgrades?
I'll get that added to the CI.
I'd propose to keep those CI specs in a central place and import them - I maintained a similar workflow in the past and it saved a lot of time duplicating work across projects + allowed developers with little CI (or Go toolchain) experience to use them out of the box. It works really well together with a template repo for projects to use as a starting point - we could start one internally (this repo is public-facing), but that's a sidenote outside the scope of this.
Yes. I will then build locally, test the resulting binary works and push a release tag once that's all looking right. |
I tried keeping the main branch filter without extra complexity/duplication, but that looks messier than its worth. Thought about yaml anchors, but those can't be shared across documents... (so the `---` separator wipes them) :(
|
@s-winkelhofer |
This fixes and updates deprecated parts of the release workflow and bumps the Go version to a non-deprecated one. (1.23.2)
It corrects broken .goreleaser.yaml and addresses all current deprecation warnings in it.
depandabotchanges are intentionally kept out the scope of this - I will have depandabot rebase off of this branch and we can go from there.Also does minor corrections to when the release step runs - now it's only on correct semver tags and only if those exist on
masterI tested this by adjusting the branch restriction to point at this branch, pushing a tag and seeing it creates a release succesfully.
I then deleted it to not confuse any potential other users of goreleaser and dropped that test commit from my branch.