open-telemetry
[infra/automation] Collector patch release updates break build because not all components are included in patch releases
What happened? Opentelemetrybot creates PRs to update the Collector version in the cascade field of the Hugo front matter whenever a new Collector release is cut. See #7542, for example. If the release is a patch, the build on the PRs often fails because not all components are included. The Collector Builder and/or Supervisor are not usually included in patch releases unless they are affected. And in some cases, only the Builder or Supervisor are included, with no corresponding update to core/contrib releases.
What did you expect would happen? We should find a way to apply patch release version updates in a more limited or nuanced way, which probably involves removing the cascade field from the top-level Collector page or leaving it in place but overriding the cascade on builder and supervisor pages (if that's possible).
Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful
context, avoiding +1 or me too, to help us triage it. Learn more here.
So, just taking a look into this, the builder versions and supervisor versions should be taken from the registry, which uses https://pkg.go.dev/go.opentelemetry.io/collector/cmd/builder?tab=versions as source of truth, which does not have the dot releases like 0.132.4
To quote from a Collector SIG meeting, here is more complete explanation of the problem:
“Yeah, so… what I want to clarify is that a lot of these patch releases were not actually patches at all, they were just reruns of the release process, because we've had issues with the release process, with Docker integration and all that, and we currently don't have a better way of rerunning the release process, … besides setting a new patch release number. So yeah, that's why some of the artifacts aren't included.
And the second thing, the second nuance, is that the version numbers on the Collector Releases repo, which correspond usually to the version numbers on Docker and all that. They don't necessarily match the releases on the Core Collector repo and the collector contrib repo. We can have a patch release in one repo, but not in another one.
And so, I think it's likely that the current documentation automation makes this assumption that they're all in sync, all the time, which is not really the case. What we've had in the past releases is essentially new versions on the collector releases repo because the release process was failing but there was no corresponding code change in the core and contrib repos and vice versa.
There also have been cases in the past, I think, where we've had patch releases in the core repo that usually lead to a patch release in the releases repo, but not on contrib. So we [the Collector SIG] need to figure out a way to keep them [the release numbers across repos] in sync, which is complicated. Or we need to make sure that they are treated distinctly, and updated distinctly, in the docs automation, which might also not be that simple.”
Thanks @tiffany76. I'll see if I can work on this before you get back. I'll assign it to myself (as a reminder for me), but others can feel free to jump in.
@tiffany76 - would it make sense / be possible to have a list of collector components each with their own version? If so, what would that list be? /cc @vitorvasc