[
https://issues.apache.org/jira/browse/YUNIKORN-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18101044#comment-18101044
]
weichen lai commented on YUNIKORN-3221:
---------------------------------------
Hi [~wilfreds] ,
I was looking into this ticket and wanted to ask for your thoughts to make sure
I’m understanding the workflow correctly.
Based on my review of the codebase:
* .go_version is already updated to 1.26 on master (via YUNIKORN-3235).
* Go 1.21+ handles GOTOOLCHAIN=auto natively out of the box, so CI and local
builds seem to pick up the right Go version without needing extra script logic.
* Reproducible builds are driven by REPRODUCIBLE_BUILDS=1 and
.go_repro_version in the sub-repositories.
Could you help clarify if there’s any specific scenario or edge case I might
have missed that we still need to handle for GOTOOLCHAIN?
> use go toolchain version for reproducible builds
> ------------------------------------------------
>
> Key: YUNIKORN-3221
> URL: https://issues.apache.org/jira/browse/YUNIKORN-3221
> Project: Apache YuniKorn
> Issue Type: Improvement
> Components: build, release
> Reporter: Wilfred Spiegelenburg
> Assignee: weichen lai
> Priority: Major
>
> Update the Go version we compile with to at least the latest 1.25.x release.
> Prepare for the change to Go 1.26 release.
> assess if we can leverage the GOTOOLCHAIN variable for (reproducible) builds.
> From the Go documentation:
> {noformat}
> When GOTOOLCHAIN is set to <name> (for example, GOTOOLCHAIN=go1.21.0), the go
> command always runs that specific Go toolchain. If a binary with that name is
> found in the system PATH, the go command uses it. Otherwise the go command
> uses a Go toolchain it downloads and verifies.{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
