[chore] Refactor goreleaser config generation for distributions

[douglascamata]

This PR will split off of #795.

This moves the code for generating the goreleaser configuration 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):

• Handling arm vs arm/v7.
• "Build-only" distro for core distro.

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.

[douglascamata]

@mowies I solved your last pending feedback and completed the release test in my fork.

I tested releasing v0.118.0 (see https://github.com/douglascamata/opentelemetry-collector-releases/tags.). The release is available at https://github.com/douglascamata/opentelemetry-collector-releases/releases/tag/v0.118.0.

Currently running my fork-built Collector in kind without any issues. The amount of artifacts produced by my fork matches the official's (452 in total).

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. :)

[mowies]

LGTM!

[douglascamata]

Let's only merge this after the release 0.119.0 goes out well... just for safety purposes. :D

[douglascamata]

@mowies I just rebased this to pick up the changes from #779. The thing is that now I'm not sure about how many release artifacts there should be for testing the release on my fork. 🤔

[mowies]

nothing should have changed in terms of artifacts, so you should still have the same number of artifacts now

[mowies]

@douglascamata did you already test your branch again?
i wanna get this in asap

[jackgopack4]

Agreed if you have a release branch in your fork to "prove your work" this otherwise looks great

[douglascamata]

@mowies, @jackgopack4: I already started the release testing on my fork for this but couldn’t finish it yet. I’ll finish it tomorrow, tackle the comments and will post the results here when I’m done. 💪

[douglascamata]

I tested releasing v0.119.0 (see https://github.com/douglascamata/opentelemetry-collector-releases/tags.). The release is available at https://github.com/douglascamata/opentelemetry-collector-releases/releases/tag/v0.119.0.

The amount of artifacts produced by my fork's release matches the official's (452 in total) and I've been running the released images from Docker Hub account in kind without any issues.

I think we are good to go.

[mx-psi]

@jpkrohling pinging you as you are doing the release on Monday, merging this since it looks good

[jackgopack4]

thank you, @mx-psi

[douglascamata]

@mx-psi @jpkrohling I’ll be available to help with the release in case something goes wrong. Just ping me on CNCF slack. 💪