Support multi-module releases in go-control-plane

[alecholmez]

This PR introduces support for multi-module releases in go-control-plane following the plan of action outlined in issue #391.

A few things have happened:

• Bumped modules to Go 1.20 (to inherit support for workspaces)
• Introduced a go workspace that orchestrates all the subcomponents of this repo
• Initialized new modules for ./envoy and ./contrib containing the generated go stubs
• Renamed build/ to scripts/ so we have a bucket for more general repo automation

When this PR is merged, a tag will be cut at v0.11.2 but a new tag will be introduced with envoy/v1.26.2. closes #391

[jpeach]

• Initialized new modules for ./envoy and ./contrib containing the generated go stubs

We probably want to do the same for ./ratelimit too?

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

[github-actions[bot]]

This pull request has been automatically closed because it has not had activity in the last 37 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

[alecholmez]

Hey all, been away for quite a while. Starting to catch back up on this project. Did we ever come to a consensus on the way forward here? I have some cycles I can spend to push this across so we can get onto a more regular release cycle.

[mmorel-35]

Hi @alecholmez , You might want to rebase your work. The go version has changed. Have you considered defining a module per extension in contrib instead of a contrib module ?

[valerian-roche]

I merged head, but my understanding is that we need to create the tags for the sub-modules first in order to allow proper importing. Trying to import in a project with the current setup, I get

 % go mod tidy
go: downloading github.com/envoyproxy/go-control-plane v0.12.1-0.20240804223412-e9538224ae87
go: github.com/envoyproxy/[email protected] requires
	github.com/envoyproxy/go-control-plane/[email protected]: invalid version: unknown revision 000000000000

In this case this PR would need:

• first create the changes within the submodules, and tag them
• this would require to follow some specific order, to add the different steps (envoy, then contrib and ratelimit, then the rest)
• update tooling to allow consistency. I'm still unclear how we can maintain consistency in tagging with a multi-module repository. We can auto-tag envoy and contrib when syncing from envoy, but we'd need to still manually update all the other modules

[mmorel-35]

Concerning the multimodule publishing mecanism, has anyone considered using opentelemetry/multimod

This seems to fit this use case

[mmorel-35]

There is one last part to be added which is the prepare-release See https://github.com/open-telemetry/opentelemetry-collector/blob/main/Makefile#L355-L393

Or https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/Makefile#L413-L426 For examples , if you'd like to take it from here as that's the crucial part that releasers will need to manipulate

[valerian-roche]

There is one last part to be added which is the prepare-release See https://github.com/open-telemetry/opentelemetry-collector/blob/main/Makefile#L355-L393

Or https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/Makefile#L413-L426 For examples , if you'd like to take it from here as that's the crucial part that releasers will need to manipulate

I pushed a few changes, and raised a separate PR to actually create the first releases. I'd then go and update the envoy sync jobs to tag when possible