x/build/cmd/releasebot: build releases regularly, automatically #29205
Comments
|
Some open-source projects release continuous “nightly” pre-release builds. Perhaps we could do the same? |
|
That's basically what I said above ("at least daily, if not hourly") But we could even go one further: we move the cmd/release + releaselet code into a package used by the coordinator and run it on every post-submit build and save the results to GCS (like we already do post-make.bash). Then Then the golang.org/dl/ handler could be modified to have some ?mode=nightly view that shows the recent unsigned binaries/installers served directly from the existing GCS snapshots. |
|
I think that this process is key to reducing the number of minor revisions. 1.11 and 1.12 have had the greatest number of minor revisions, so it looks like the trend has been that the number increases with every major release. |
|
@smasher164 we switched to doing monthly point releases during that time, so it's an unrelated metric. |
This comment has been minimized.
This comment has been minimized.
dmitshur
added
the
NeedsInvestigation
|
Change https://golang.org/cl/229483 mentions this issue: |
|
Change https://golang.org/cl/229482 mentions this issue: |
The Go Project page is copied from Go master as of 2020/04/24 (commit golang/go@ee8972c, CL 209679). This page not closely tied to specific Go releases, and thus is better suited to live in the x/website repo. It will be modified in CL 229483 to use the release history data from the internal/history package, rather than using hand-written HTML which needs to be updated manually after each major Go release. For golang/go#29205. For golang/go#29206. Change-Id: I6a6fa734fb3d873da59d67d796616fc53d684610 Reviewed-on: https://go-review.googlesource.com/c/website/+/229482 Reviewed-by: Alexander Rakoczy <alex@golang.org>
This change builds on what was done in CL 229081, and uses the Go release history data from internal/history package to generate the list of major Go versions on the Go project page. This way, this page doesn't need to be manually edited when major Go releases are made. For golang/go#38488. For golang/go#29205. For golang/go#29206. Change-Id: Ie0b12707d828207173a54f0a1bc6a4ef69dcedef Reviewed-on: https://go-review.googlesource.com/c/website/+/229483 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alexander Rakoczy <alex@golang.org>
|
Change https://golang.org/cl/245277 mentions this issue: |
|
Change https://golang.org/cl/382055 mentions this issue: |
Bryan and I discussed that it might be a good idea to move the logic that sets -mmacosx-version-min=nnn via CGO_CFLAGS on GOOS=darwin from x/build/cmd/release to the cmd/go command. That way, if a problem happens, it's reported not only during tests that the release script runs, but also during normal pre/post-submit builders, thus sooner. Until that happens (and in case it doesn't), set this environment variable on at least one of our darwin/amd64 builders to improve our test coverage for this edge case. This is inexpensive to do compared to adding an entire new builder, and can be done quickly. This is one of minor differences in environment between the tests that run during by builders and during the release, and the long term plan to catch all of them is still via nightly releases. For golang/go#50892. Updates golang/go#29205. Change-Id: I5dd9a2f1dd457f54db6590d4ee181f81df8f7c38 Reviewed-on: https://go-review.googlesource.com/c/build/+/382055 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Trust: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
|
I think we can probably close this in favor of #40279, since the scope of that issue covers everything mentioned here, and it'll be in |
The Go Project page is copied from Go master as of 2020/04/24 (commit golang/go@ee8972c, CL 209679). This page not closely tied to specific Go releases, and thus is better suited to live in the x/website repo. It will be modified in CL 229483 to use the release history data from the internal/history package, rather than using hand-written HTML which needs to be updated manually after each major Go release. For golang/go#29205. For golang/go#29206. Change-Id: I6a6fa734fb3d873da59d67d796616fc53d684610 Reviewed-on: https://go-review.googlesource.com/c/website/+/229482 Reviewed-by: Alexander Rakoczy <alex@golang.org>
This change builds on what was done in CL 229081, and uses the Go release history data from internal/history package to generate the list of major Go versions on the Go project page. This way, this page doesn't need to be manually edited when major Go releases are made. For golang/go#38488. For golang/go#29205. For golang/go#29206. Change-Id: Ie0b12707d828207173a54f0a1bc6a4ef69dcedef Reviewed-on: https://go-review.googlesource.com/c/website/+/229483 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alexander Rakoczy <alex@golang.org>
Every release comes with surprises/problems with releasebot.
If releasebot was always running it would be less scary and prone to breakage.
Or we'd catch problems earlier.
We should be building automatic unsigned releases all the time. (at least daily, if not hourly)
/cc @dmitshur @andybons @bcmills @toothrot @cagedmantis
The text was updated successfully, but these errors were encountered: