x/build/cmd/coordinator, x/build/maintner/maintnerd/maintapi: golang.org/x repo trybot on custom release branch should use corresponding Go branch #42127
Labels
Builders
x/build issues (builders, bots, dashboards)
FrozenDueToAge
NeedsFix
The path to resolution is known, but the work has not been done.
Milestone
Comments
dmitshur
added
Builders
|
The problem is on this line: When a release branch has a suffix (like "-bundle"), the A fix to allow suffixes separated by a dash could be to change that to |
dmitshur
added
NeedsFix
|
Change https://golang.org/cl/264203 mentions this issue: |
dmitshur
changed the title
dmitshur
changed the title
|
Change https://golang.org/cl/319789 mentions this issue: |
gopherbot
pushed a commit
to golang/build
that referenced
this issue
May 17, 2021
…ch logic This change reverts the coordinator side to be much simpler, as it was before CL 167382, and consolidates all the version selection in maintapi. This direction is chosen because at this time¹ maintapi is best suited to perform version selection. This is a refactor CL that leaves current behavior unmodified, and test cases provide improved coverage. The following smaller CL will make the desired changes to behavior. Remove TestNewTrySetBuildRepoGo110 because it's no longer needed. It was added when x/build started requiring module mode to build successfully, given that Go 1.10 didn't have module mode support. Background At this time¹ coordinator makes use of maintapi to find TryBot work, and it is a collaborate effort between the two components that results in determining what builds will happen. Coordinator is ultimately responsible for starting and running the builds, but it doesn't have information about the branches in the Go project (the Go revision at refs/heads/master, refs/heads/release-branch.go1.16, etc.). Maintapi has that information via the maintner corpus. So it makes the version information available to coordinator by populating relevant fields in apipb.GoFindTryWorkResponse. Issue golang/go#28891 was about wanting to test golang.org/x repo CLs on release-branch.go1.n with the corresponding Go 1.n version, rather than Go tip. Unfortunately, it was implemented on the coordinator side, resulting in the logic for version selection to be more spread between the coordinator and maintapi components. There were followup issues like golang/go#42127 and golang/go#37512, whose fixes built on top of the coordinator side, and increased complexity there. As a consequence, making and testing further changes became more difficult than it needs to be. ¹ After golang/go#34744 is done, I'd like to move all the TryBot version selection logic into coordinator, the component responsible for TryBots. But not today. For golang/go#46154. Change-Id: I93986acefd4bf66b27ccf0323439966122b7989a Reviewed-on: https://go-review.googlesource.com/c/build/+/319789 Trust: Dmitri Shuralyov <[email protected]> Run-TryBot: Dmitri Shuralyov <[email protected]> TryBot-Result: Go Bot <[email protected]> Reviewed-by: Carlos Amedee <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
When trybots are testing a CL in a golang.org/x to a release branch with a custom suffix (e.g.,
release-branch.go1.14-cmdorrelease-branch.go1.15-bundle), they should use the mentioned Go version to test that CL, not tip.See CL 264058 where Go tip (1.16) was used, despite the release branch having a "go1.15" in it.
This is somewhat related to issues #37512 and #38303. Custom release branches are somewhat unusual (now for #41375, last time for #36851) and hopefully won't come up much in the future.
CC @golang/release.
The text was updated successfully, but these errors were encountered: