-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Go 1.22 support (including vendored workspaces) #553
base: main
Are you sure you want to change the base?
Conversation
When commit e0732c7 enabled full Go 1.21 support the semantics it used for the Go toolchain selection conditions was very unfortunate as it revolved too much around the 'go_max_version' variable which at the time was set to be 1.21. The problem there is that once we try bumping the max version to say 1.22 the conditions stop making sense and as a bonus the existing tests start failing. The reasons for that are the following: - we're not actually planning on updating the container image with each Go version we're going to support unless absolutely necessary; that is thanks to the GOTOOLCHAIN=auto mechanism introduced by 1.21 that will download any new toolchain as needed automatically - without changing unit tests we suddenly can't pass the trivial condition on selecting the old fallback 1.20 if the existing unit test's base Go release is 1.21.X and the new max supported version is 1.22 Tweak the selection conditions so that they finally make sense semantically: - use go_max_version only to check incoming requests for incompatible new releases - otherwise always explicitly compare against 1.21 and only fall back to 1.20 if the base release is above 1.21 which would lead to dirtying the source repo due to compatibility issues on Golang's side Fixes: e0732c7 Signed-off-by: Erik Skultety <[email protected]>
This commit introduces just preliminary support of 1.22, i.e. without vendored workspaces support. Future patches will take care of adding support for vendored workspaces. Signed-off-by: Erik Skultety <[email protected]>
Introduced by Go 1.22 and controlled via 'go mod vendor'. We already can work with plain module vendoring, so this is just a minor change for us where based on detecting whether workspaces are in use along with vendoring we just switch the command from 'go mod vendor' to 'go work vendor'. Signed-off-by: Erik Skultety <[email protected]>
Signed-off-by: Erik Skultety <[email protected]>
b361dd9
to
63e6800
Compare
Since v1:
@chmeliik @brunoapimentel I'm ambivalent on the decision to test this in an e2e test (I did make sense to me to verify building with everything vendored, i.e. we didn't need to fetch anything, also there's a lack of real projects to test the feature with), so let me know if you want me to model it as a basic integration test or e2e is fine. Note: Due to the ^above the integration test currently points to my own fork and based on the decision and the overall acceptance of the integration test I will push the change to the test origin repo. |
@@ -1525,6 +1527,7 @@ def parse_module_line(line: str) -> ParsedModule: | |||
def _vendor_deps( | |||
go: Go, | |||
app_dir: RootedPath, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we still need to handle the app_dir vs. workspace root mismatch
packages=({"path": "hi/hiii", "type": "gomod"},),
flags=["--gomod-vendor"],
This means that the app_dir
will be hi/hiii
and so cachi2 will try to parse hi/hiii/vendor/modules.txt
, which doesn't exist. We should parse the root vendor/modules.txt
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested with https://github.com/cachito-testing/gomod-pandemonium/tree/go-1.22-workspace-vendoring
cachi2 --log-level debug fetch-deps '{"type": "gomod", "path": "."}' --gomod-vendor
cp cachi2-output/bom.json root-bom.json
cachi2 --log-level debug fetch-deps '{"type": "gomod", "path": "terminaltor"}' --gomod-vendor
cp cachi2-output/bom.json submodule-bom.json
get_module_purls() {
jq < "$1" '.components[].purl | select(test("type=module"))' -r | sort -u
}
comm -23 <(get_module_purls root-bom.json) <(get_module_purls submodule-bom.json)
pkg:golang/github.com/Azure/[email protected]?type=module
pkg:golang/github.com/google/[email protected]?type=module
pkg:golang/github.com/go-task/[email protected]?type=module
pkg:golang/github.com/Microsoft/[email protected]?type=module
pkg:golang/golang.org/x/[email protected]?type=module
^ currently, these are only identified if you're processing the workspace root
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even after fixing the modules.txt parsing, there's still a problem with reporting packages:
get_nonstd_purls() {
jq < "$1" '.components[].purl | select(test("^pkg:golang/[^/]*\\.[^/]*/"))' -r | sort -u
}
comm -23 <(get_nonstd_purls root-bom.json) <(get_nonstd_purls submodule-bom-fixed.json)
pkg:golang/github.com/cachito-testing/[email protected]?type=package
pkg:golang/github.com/cachito-testing/gomod-pandemonium/[email protected]?type=package
pkg:golang/github.com/cachito-testing/retrodep/v2/retrodep/[email protected]?type=package
pkg:golang/github.com/cachito-testing/retrodep/v2/[email protected]?type=package
pkg:golang/github.com/Masterminds/[email protected]?type=package
pkg:golang/github.com/op/[email protected]?type=package
pkg:golang/github.com/pkg/[email protected]?type=package
pkg:golang/golang.org/x/sys/[email protected]?type=package
pkg:golang/golang.org/x/tools/go/[email protected]?type=package
pkg:golang/gopkg.in/[email protected]?type=package
It looks like go list ./...
isn't "workspace-aware", so we will need to run that in the workspace root as well. We can probably make that part of the bigger rework
Basic would have been enough IMO, but there's no harm in keeping it e2e when it's already e2e |
@eskultety do you know when we can start using Go 1.22 in Konflux ? I'm getting
and I'm assuming the feature request has been already requested somewhere given this PR |
@pierDipi do you use vendored workspaces? If so, this work is still in progress, if not, this PR is not the right place to discuss - #591 |
Go 1.22 introduced another toolkit feature that affects cachi2 directly - vendored workspaces meaning that projects can now combine the vendoring feature (local module replacements) and workspaces (controlling local modules centrally wrt/ dependencies and language version requirements).
Go enabled this via a new subcommand
go work vendor
which needs to be run instead of the existinggo mod vendor
. This looks like the only difference and so we should be able to address it very simply by running that modified vendoring command when we detect the project uses workspaces.Given the low complexity of the code no design doc accompanies this PoC as the changes should be straightforward, provided we finish the workspaces support in #457.
Note this PoC is based on work proposed in #457 so as such we need to wait for that PR before we consider this to be merged.References: #398
Notes:
GOWORK=off
) downstream version of hypershiftMaintainers will complete the following section
Note: if the contribution is external (not from an organization member), the CI
pipeline will not run automatically. After verifying that the CI is safe to run:
/ok-to-test
(as is the standard for Pipelines as Code)