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: support trybot/slowbot runs with GOEXPERIMENT=... #42678

Open
thanm opened this issue Nov 17, 2020 · 6 comments
Open

x/build: support trybot/slowbot runs with GOEXPERIMENT=... #42678

thanm opened this issue Nov 17, 2020 · 6 comments
Labels
Builders x/build issues (builders, bots, dashboards) NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unreleased

Comments

@thanm
Copy link
Contributor

thanm commented Nov 17, 2020

The slowbots feature (e.g. setting "TRY=") is extremely helpful for developers who want to get expanded test coverage for their CLs (particularly with the more obscure GOOS/GOARCH combos). This was a big help for the team when rewriting the linker this last year.

Another feature that would make developers lives easier would be to allow the setting of GOEXPERIMENT=... in a Gerrit reply or comment, and then have that setting picked up and used when doing the builder runs.

Two cases that come to mind immediately are field tracking, e.g. GOEXPERIMENT=fieldtrack, which seems to break on a semi-regular basis due to lack of regular testing, and GOEXPERIMENT=regabi. At the moment developers working on the register ABI project can do local testing by setting GOEXPERIMENT before running make.bash or all.bash, but there isn't an easy way for them to do testing over a wider set of builders.
@gopherbot gopherbot added the Builders x/build issues (builders, bots, dashboards) label Nov 17, 2020
@gopherbot gopherbot added this to the Unreleased milestone Nov 17, 2020
@mdempsky
Copy link
Member

Related: I've proposed #42681, which might help here.

@bcmills
Copy link
Contributor

bcmills commented Nov 18, 2020 •
edited

In general, supported configurations should have builders running at every commit, not just when specific TryBots are requested: for example, linux-amd64-staticlockranking is its own builder.¹

Is there a reason that strategy cannot be employed for the other GOEXPERIMENT settings of interest?

¹ https://github.com/golang/build/blob/07fdb09614b7efbb9c1e733f5bf5e880cbac53d2/dashboard/builders.go#L1674-L1688

@thanm
Copy link
Contributor Author

thanm commented Nov 18, 2020

@bcmills having a builder per viable GOEXPERIMENT (as with staticlockranking) would work for me. Assuming that we decide to continue with GOEXPERIMENT in the first place.

@thanm
Copy link
Contributor Author

thanm commented Nov 18, 2020

One thing I should add: with some experiments it makes sense to have just a single builder (ex: field tracking, static lock ranking), but there could easily be experiments that we want to test on a wider set of architecture/OS combinations.

@bcmills
Copy link
Contributor

bcmills commented Nov 18, 2020

If there are configurations for which we want to run the standard tests to prevent regressions, those configurations should have builders even if we use some other mechanism instead of GOEXPERIMENT. (The Beyoncé Rule applies here.)

@cagedmantis cagedmantis added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 30, 2020
@cagedmantis
Copy link
Contributor

/cc @golang/release

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Builders x/build issues (builders, bots, dashboards) 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
5 participants
@mdempsky @cagedmantis @bcmills @gopherbot @thanm