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.

Sign up for GitHub

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

Jump to bottom

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
Unreleased

Comments

@bradfitz
Copy link
Contributor

bradfitz commented Dec 12, 2018 •
edited by dmitshur
Loading

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.

Sign in to view
@toothrot toothrot self-assigned this Feb 7, 2020
@dmitshur dmitshur added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Apr 16, 2020
@dmitshur dmitshur mentioned this issue Apr 16, 2020
Closed
@dmitshur dmitshur self-assigned this Apr 16, 2020
@dmitshur dmitshur mentioned this issue Apr 16, 2020
Closed
@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
@dmitshur
content/static/doc: copy The Go Project page (contrib.html) from Go repo
70f4ee8 
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>
gopherbot pushed a commit to golang/website that referenced this issue Apr 24, 2020
@dmitshur
cmd/golangorg: generate major version list on Go project page
0d8ef50 
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>
@gopherbot
Copy link
Contributor

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

@dmitshur dmitshur mentioned this issue Sep 10, 2020
Open
@dmitshur dmitshur mentioned this issue Sep 21, 2020
Open
@dmitshur dmitshur mentioned this issue May 20, 2021
Closed
@bcmills bcmills mentioned this issue Jun 24, 2021
Open
@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
@dmitshur
dashboard: test with -mmacosx-version-min set on darwin-amd64-10_15
015a2a0 
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>
@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
@passionSeven
content/static/doc: copy The Go Project page (contrib.html) from Go repo
b1d9d6a 
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>
passionSeven added a commit to passionSeven/website that referenced this issue Oct 18, 2022
@passionSeven
cmd/golangorg: generate major version list on Go project page
561a0d2 
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>
@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.
Assignees
No one assigned
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
Milestone
Unreleased
Development

No branches or pull requests
7 participants
@bradfitz @toothrot @andybons @dmitshur @bcmills @gopherbot @smasher164