x/build: create VERSION file for cmd/dist to read #24754
Comments
Well, this part of the failure log (https://build.golang.org/log/89d71a5b0369a691899c3435abc7df3d4abd4074) is interesting:
The build system is explicitly writing out a VERSION file, and then something is changing it. Why? @rsc added that in b09e2de where he says: + // Some builders cross-compile the toolchain on linux-amd64
+ // and then copy the toolchain to the target builder (say, linux-arm)
+ // for use there. But on non-release (devel) branches, the compiler
+ // used on linux-amd64 will be an amd64 binary, and the compiler
+ // shipped to linux-arm will be an arm binary, so they will have different
+ // content IDs (they are binaries for different architectures) and so the
+ // packages compiled by the running-on-amd64 compiler will appear
+ // stale relative to the running-on-arm compiler. Avoid this by setting
+ // the version string to something that doesn't begin with devel.
+ // Then the version string will be used in place of the content ID,
+ // and the packages will look up-to-date.
+ // TODO(rsc): Really the builders could be writing out a better VERSION file instead,
+ // but it is easier to change cmd/dist than to try to make changes to
+ // the builder while Brad is away.
+ if strings.HasPrefix(b, "devel") {
+ if hostType := os.Getenv("META_BUILDLET_HOST_TYPE"); strings.Contains(hostType, "-cross") {
+ fmt.Fprintf(os.Stderr, "warning: changing VERSION from %q to %q\n", b, "builder "+hostType)
+ b = "builder " + hostType
+ }
+ } So, uh, what should the VERSION file be, @rsc? |
Change https://golang.org/cl/106118 mentions this issue: |
Updates golang/go#24754 Change-Id: Ie5e94a8fd0b76e6394249a734d8fc1a61650dbad Reviewed-on: https://go-review.googlesource.com/106118 Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
@bradfitz the builder is still seeing the same failures. Do we require manual action to apply your dashboard fix above? |
I haven't deployed it |
Ah, apologies for the noise - I thought this was somehow automated. |
Ping @rsc. What do you think the VERSION file should contain in these cases? |
@bradfitz The reason for the change is, essentially, to avoid having the string The output of So this all boils down to: Other than not starting with |
@ianlancetaylor, one medium-term goal for the builders is to use cmd/go's build+test cache infrastructure across builds, at least for trybots. If we put the git commit hash in the VERSION, doesn't that get mixed in to the action ID / cache keys? Can I just use a static string for all builds, like |
I don't understand how we can safely use the cache across builds across CLs. If a CL changes the compiler, then we definitely do not want to pick up an cached build result built by an earlier version of the compiler. |
@ianlancetaylor, I assumed the digest of the compiler/linker/assembler bits were part of the cache. I just don't want some arbitrary string to be part of the digest unnecessarily. If a given commit only touches a comment in some test file, I want to have an identical compiler/linker/assembler from the previous commit, and then reuse all the built packages & test results. |
If At least, that is my understanding. |
https://build.golang.org/log/89d71a5b0369a691899c3435abc7df3d4abd4074
The fact that the version does not contain
devel
implies that+pkg
lines, i.e. new APIs, are a test failure:The fact that no other builder hits this tells me that the version in this ARM builder is wrong; it should contain
devel
.The text was updated successfully, but these errors were encountered: