Skip to content
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

x/build/cmd/releasebot: build releases regularly, automatically #29205

Closed
bradfitz opened this issue Dec 12, 2018 · 10 comments
Closed

x/build/cmd/releasebot: build releases regularly, automatically #29205

bradfitz opened this issue Dec 12, 2018 · 10 comments
Labels
Builders x/build issues (builders, bots, dashboards) FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@bradfitz
Copy link
Contributor

bradfitz commented Dec 12, 2018

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

@gopherbot gopherbot added this to the Unreleased milestone Dec 12, 2018
@gopherbot gopherbot added the Builders x/build issues (builders, bots, dashboards) label Dec 12, 2018
@bcmills
Copy link
Contributor

bcmills commented Dec 12, 2018

Some open-source projects release continuous “nightly” pre-release builds. Perhaps we could do the same?

@bradfitz
Copy link
Contributor Author

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 x/build/cmd/release basically does nothing except wait for the unsigned build to finish building normally and then pulls the unsigned builds from GCS for signing and uploads them to the right place post-signing.

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.

@smasher164
Copy link
Member

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.

@andybons
Copy link
Member

@smasher164 we switched to doing monthly point releases during that time, so it's an unrelated metric.

@smasher164

This comment has been minimized.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/229483 mentions this issue: cmd/golangorg: generate major version list on Go project page

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/229482 mentions this issue: content/static/doc: copy The Go Project page (contrib.html) from Go repo

gopherbot pushed a commit to golang/website that referenced this issue Apr 24, 2020
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 <[email protected]>
gopherbot pushed a commit to golang/website that referenced this issue Apr 24, 2020
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 <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Alexander Rakoczy <[email protected]>
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/245277 mentions this issue: maintner/maintnerd/maintapi/version: support beta and RC release tags

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/382055 mentions this issue: dashboard: test with -mmacosx-version-min set on darwin-amd64-10_15

gopherbot pushed a commit to golang/build that referenced this issue Feb 1, 2022
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 <[email protected]>
Trust: Dmitri Shuralyov <[email protected]>
Reviewed-by: Carlos Amedee <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
@dmitshur
Copy link
Contributor

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 cmd/relui rather than cmd/releasebot.

@dmitshur dmitshur closed this as not planned Won't fix, can't repro, duplicate, stale Jun 13, 2022
passionSeven added a commit to passionSeven/website that referenced this issue Oct 18, 2022
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 <[email protected]>
passionSeven added a commit to passionSeven/website that referenced this issue Oct 18, 2022
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 <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Alexander Rakoczy <[email protected]>
@golang golang locked and limited conversation to collaborators Jun 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Builders x/build issues (builders, bots, dashboards) FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

7 participants