Specify full x.y.z version of Go in go.mod #1442
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
JIRA: https://issues.redhat.com/browse/RHOAIENG-16819 It seems like on some platforms, when the local installation installation of Go decides that it needs to download a different toolchain, that it may fail unless we either specify a full x.y.z version in the `go` directive, or explicitly specify the `toolchain` directive. I believe for our uses, using a fully specified x.y.z `go` directive value is preferable, to prevent any issues with explicitly defining a toolchain where we might have a newer version in a container image build that has a default of `GOTOOLCHAIN='local'` (I'm not 100% sure if that would cause any issues, but I'm 100% sure that the way proposed in this commit shouldn't).
|
/cc @VaishnaviHire This is a follow up to #1439 after feedback in #1440 (comment) |
|
/lgtm needs rebase ;( |
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1442 +/- ##
=======================================
Coverage ? 19.71%
=======================================
Files ? 149
Lines ? 10052
Branches ? 0
=======================================
Hits ? 1982
Misses ? 7846
Partials ? 224 ☔ View full report in Codecov by Sentry. |
I wonder if that was a GH blip, or a change with how it works? 🤔 I also saw that message that it was out of date with the base branch, but now it says the following for me, which seems to indicate that it'll get auto-merged fine once it gets the approved label:
Edit: I'm using the "new merge experience" ( |
No idea, I checked the merge itself :) |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: VaishnaviHire The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
79e1b94
into
opendatahub-io:main
10 checks passed
zdtsw
pushed a commit
to zdtsw-forking/opendatahub-operator
that referenced
this pull request
Jan 2, 2025
JIRA: https://issues.redhat.com/browse/RHOAIENG-16819 It seems like on some platforms, when the local installation installation of Go decides that it needs to download a different toolchain, that it may fail unless we either specify a full x.y.z version in the `go` directive, or explicitly specify the `toolchain` directive. I believe for our uses, using a fully specified x.y.z `go` directive value is preferable, to prevent any issues with explicitly defining a toolchain where we might have a newer version in a container image build that has a default of `GOTOOLCHAIN='local'` (I'm not 100% sure if that would cause any issues, but I'm 100% sure that the way proposed in this commit shouldn't). (cherry picked from commit 79e1b94)
5 tasks
zdtsw
added a commit
that referenced
this pull request
Jan 2, 2025
* Update Dockerfiles to Go 1.22 (#1424) JIRA: https://issues.redhat.com/browse/RHOAIENG-16819 The UBI8 go-toolset image that we use for building is already on 1.22, so I don't think there's any reason to remain bound to 1.21. Also, upstream Go only support the two most recent minor versions: currently that means 1.23 and 1.22; 1.21 is no longer receiving any updates from the Go developers. * Update Go version in go.mod to 1.22 (Go 1.22: 2/3) (#1439) * Update Dockerfiles to Go 1.22 JIRA: https://issues.redhat.com/browse/RHOAIENG-16819 The UBI8 go-toolset image that we use for building is already on 1.22, so I don't think there's any reason to remain bound to 1.21. Also, upstream Go only support the two most recent minor versions: currently that means 1.23 and 1.22; 1.21 is no longer receiving any updates from the Go developers. * Update Go version in go.mod to 1.22 JIRA: https://issues.redhat.com/browse/RHOAIENG-16819 This just updates the Go version in the go directive in go.mod. The code changes to add nolint suppression is temporary and those will be addressed in a separate commit. (cherry picked from commit 5f456ad) * Specify full x.y.z version of Go in go.mod (#1442) JIRA: https://issues.redhat.com/browse/RHOAIENG-16819 It seems like on some platforms, when the local installation installation of Go decides that it needs to download a different toolchain, that it may fail unless we either specify a full x.y.z version in the `go` directive, or explicitly specify the `toolchain` directive. I believe for our uses, using a fully specified x.y.z `go` directive value is preferable, to prevent any issues with explicitly defining a toolchain where we might have a newer version in a container image build that has a default of `GOTOOLCHAIN='local'` (I'm not 100% sure if that would cause any issues, but I'm 100% sure that the way proposed in this commit shouldn't). (cherry picked from commit 79e1b94) * Address new linter errors introduced with Go 1.22 (#1440) JIRA: https://issues.redhat.com/browse/RHOAIENG-16819 (cherry picked from commit e30eb81) * fix: add nolint for loop Signed-off-by: Wen Zhou <wenzhou@redhat.com> * update: remove instead of skipping lint Signed-off-by: Wen Zhou <wenzhou@redhat.com> --------- Signed-off-by: Wen Zhou <wenzhou@redhat.com> Co-authored-by: Gerard Ryan <git@grdryn.xyz>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
JIRA: https://issues.redhat.com/browse/RHOAIENG-16819
Description
It seems like on some platforms, when the local installation
installation of Go decides that it needs to download a different
toolchain, that it may fail unless we either specify a full x.y.z
version in the
godirective, or explicitly specify thetoolchaindirective.
I believe for our uses, using a fully specified x.y.z
godirectivevalue is preferable, to prevent any issues with explicitly defining a
toolchain where we might have a newer version in a container image
build that has a default of
GOTOOLCHAIN='local'(I'm not 100% sureif that would cause any issues, but I'm 100% sure that the way
proposed in this commit shouldn't).
How Has This Been Tested?
Screenshot or short clip
Merge criteria