[chore] Refactor goreleaser config generation for distributions #797
Conversation
…tor-releases into fancy-approach-windows-build
…a/opentelemetry-collector-releases into refactor-go-releaser-config
So now the order should be: - consts - global vars - interfaces - structs and their methods - loose funcs
|
@mowies I think I handled all the feedback you gave so far. I will refrain from anything that would require a forced-push from now on so that reviews become easier as you can use the "commits since your last review" feature. Thank you very much for your time and review. 🙇 By the way, I was about to unexport everything that is unnecessarily exported (that's everything except the |
cool, i'll take another look now
that's good, let's rather have a few follow up PRs :) |
There was a problem hiding this comment.
LGTM! I still think you could move all/most interfaces and structs to the top of the file but that's mostly just my taste.
Additional follow ups that I see:
- moving things into separate files where it makes sense
A full test release in your fork would be good to verify that everything works and that the same amount of release assets is produced in the end
…tor-releases into refactor-go-releaser-config
…tor-releases into refactor-go-releaser-config
|
@mowies I solved your last pending feedback and completed the release test in my fork. I tested releasing Currently running my fork-built Collector in I think this is looking good. Regarding the follow ups, I can and want to split this into multiple files organize it even better. I also plan to removed any unnecessaraly exported symbols and, last but not least, proceed with the work to add Windows container images. There are some nice adventures to come. :) |
|
Let's only merge this after the release 0.119.0 goes out well... just for safety purposes. :D |
Also added the ppc64/power8 arch.
…a/opentelemetry-collector-releases into refactor-go-releaser-config
…tor-releases into refactor-go-releaser-config
|
nothing should have changed in terms of artifacts, so you should still have the same number of artifacts now |
|
@douglascamata did you already test your branch again? |
| goos: | ||
| - linux | ||
| goarch: | ||
| - amd64 | ||
| - arm64 | ||
| - ppc64le | ||
| - s390x | ||
| goppc64: |
There was a problem hiding this comment.
this should still be there i believe
| // func (b *distributionBuilder) WithBuildOnlyPackaging() *distributionBuilder { | ||
| // return b.WithOnlyBinArchive(). | ||
| // WithDefaultChecksum(). | ||
| // WithDefaultNfpms(). | ||
| // WithDefaultMSIConfig(). | ||
| // WithDefaultSigns(). | ||
| // WithDefaultDockerSigns(). | ||
| // WithDefaultSBOMs() | ||
| // } |
This PR will split off of #795.
This moves the code for generating the
goreleaserconfiguration for the distros into a more declarative and easy-to-extend form.Why so many changes? 😱
I am completely aware that it represents a big rewrite of this part of code. I tried a few different approaches with the intent of having a minimum change that would allow me to support Windows, but the amount of changes needed always ended up snowballing quickly. Some examples of the reasons for this "snowballing" of code are (non-exhaustive list):
This might not the best code for this job too, but at least I believe it sets up a good structure that we can build upon and iterate on to improve.
I'm very open to hear your feedback and see how we can move this forward!
I can join the Collector SIG call on 2025-01-15 to talk about this if any maintainer finds it more productive.
Questions ⍰
If anyone, please, could help me out in testing that release process works fine with the update goreleaser configuration, it would be aaaaamazing! I don't feel super confident without testing this, of course.