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: make GOROOT read-only before running tests #30316

Open
bcmills opened this Issue Feb 19, 2019 · 8 comments

Comments

Projects
None yet
4 participants
@bcmills
Copy link
Member

bcmills commented Feb 19, 2019

When #28387 is fixed, we should make sure that it doesn't regress.

Can we configure the builders to make GOROOT read-only before they invoke run.bash, and perhaps restore write permissions after the tests have finished?

(CC @bradfitz @dmitshur)

@gopherbot gopherbot added this to the Unreleased milestone Feb 19, 2019

@gopherbot gopherbot added the Builders label Feb 19, 2019

@dmitshur

This comment has been minimized.

Copy link
Member

dmitshur commented Feb 19, 2019

Is it better to catch regressions to #28387 by making builders have a read-only GOROOT and hope that tests fail if they try to write, or by having a writeable GOROOT and try to verify (after tests have finished running) that GOROOT hasn't been modified?

I'm not sure if it's viable to do the latter, but I wanted to ask so that we consider it.

@bradfitz

This comment has been minimized.

Copy link
Member

bradfitz commented Feb 19, 2019

and perhaps restore write permissions after the tests have finished?

After the tests have finished we destroy the VM, so not point restoring write access moments before death.

@bcmills

This comment has been minimized.

Copy link
Member Author

bcmills commented Feb 19, 2019

@dmitshur, we could do both, but it is more important to run with a read-only GOROOT and check for failing tests: tests that leave changes behind are easy for developers to detect (via git status), so they slip by much less frequently than tests that make and then unmake ephemeral changes.

The latter category is still harmful, since they will fail when users run go test all (a command intended to become more useful in module mode) with a distro-packaged copy of the Go toolchain.

Ephemeral changes can also interfere with proper cache invalidation, so we should avoid them even if GOROOT is writable.

@bcmills

This comment has been minimized.

Copy link
Member Author

bcmills commented Feb 19, 2019

(It occurs to me, though, that we already have a “files opened” check in the cache subsystem. Probably we should check for — and reject — file writes in GOROOT explicitly there.)

@bradfitz

This comment has been minimized.

Copy link
Member

bradfitz commented Feb 21, 2019

The buildlet already has a recursive file list endpoint, so the build system could also just look at all files before & after a test run to see if there are any differences. This is what x/build/cmd/gomote does to decide how to incrementally push files from developer machines to buildlets.

That might be faster in that it's only doing read operations and not writes.

@bcmills

This comment has been minimized.

Copy link
Member Author

bcmills commented Feb 21, 2019

As noted above, merely looking at the files before and after the test run is not sufficient: we don't want tests to make ephemeral changes, even if they back them out before exiting.

@bradfitz

This comment has been minimized.

Copy link
Member

bradfitz commented Feb 21, 2019

Ah, sorry, missed that comment.

@gopherbot

This comment has been minimized.

Copy link

gopherbot commented Feb 22, 2019

Change https://golang.org/cl/163477 mentions this issue: cmd/dist: make GOROOT unwritable on builders

@bcmills bcmills added the NeedsFix label Feb 28, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.