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

proposal: cmd/go: build argument to disable readonly $GOPATH/pkg/mod #31481

Closed
Psykar opened this issue Apr 16, 2019 · 36 comments
Closed

proposal: cmd/go: build argument to disable readonly $GOPATH/pkg/mod #31481

Psykar opened this issue Apr 16, 2019 · 36 comments
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Proposal
Milestone

Comments

@Psykar
Copy link

Psykar commented Apr 16, 2019

What did you do?

This has been discussed previously:
#27161

Most build systems (buildroot et al.) expect to be able to do an rm -rf to do a completely fresh build. However, because the pkg sets it's containing directories to read only, this command will fail.

Requiring a custom command to be added to various Makefile's scattered around the place to clean this up is far from ideal.

A potential solution might be to add an environment variable to disable this read only permission change on the pkg directory.
Open to other alternatives - but ideally there needs to be a command on the BUILD side that allows rm -rf to work correctly.

Psykar added a commit to Psykar/buildroot that referenced this issue Apr 16, 2019
Some build systems (looking at you golang) create read only directories
as caches.
As such rm -rf will actually fail, causing clean and <pkg>-dirclean to fail.

This patch will cause `make clean` to run chmod -R +w on the relevant
directory first, which will allow rm -rf to work.

This may be resolved if golang/go#31481 is
resolved satisfactorily.

Signed-off-by: Louis des Landes <[email protected]>
Psykar added a commit to Psykar/buildroot that referenced this issue Apr 16, 2019
Some build systems (looking at you golang) create read only directories
as caches.
As such rm -rf will actually fail, causing clean and <pkg>-dirclean to fail.

This patch will cause `make <pkg>-dirclean` to force chmod -R +w on the relevant
directory first, which will allow rm -rf to work.

This may be resolved if golang/go#31481 is
resolved satisfactorily.

Signed-off-by: Louis des Landes <[email protected]>
Psykar added a commit to Psykar/buildroot that referenced this issue Apr 16, 2019
Some build systems (looking at you golang) create read only directories
as caches.
As such rm -rf will actually fail, causing clean and <pkg>-dirclean to fail.

This patch will cause `make clean` to run chmod -R +w on the relevant
directory first, which will allow rm -rf to work.

This may be resolved if golang/go#31481 is
resolved satisfactorily.

Signed-off-by: Louis des Landes <[email protected]>
Psykar added a commit to Psykar/buildroot that referenced this issue Apr 16, 2019
Some build systems (looking at you golang) create read only directories
as caches.
As such rm -rf will actually fail, causing clean and <pkg>-dirclean to fail.

This patch will cause `make <pkg>-dirclean` to force chmod -R +w on the relevant
directory first, which will allow rm -rf to work.

This may be resolved if golang/go#31481 is
resolved satisfactorily.

Signed-off-by: Louis des Landes <[email protected]>
@agnivade
Copy link
Contributor

#27161 clearly mentions that it is intentional and will remain this way.

It would be good if your proposal addresses the issue raised by @rsc here.

@dmitshur dmitshur changed the title Build argument to disable readonly $GOPATH/pkg/mod cmd/go: Build argument to disable readonly $GOPATH/pkg/mod Apr 16, 2019
@Psykar
Copy link
Author

Psykar commented Apr 17, 2019

@agnivade - the default being read only makes complete sense to me, I'm not suggesting changing that.
I would have thought a manual flag to allow the directories to be writeable would be acceptable - to tell golang that I know what I'm doing, it's OK to not lock the directory down?

It's worth noting in this kind of scenario (embedded build systems), tests are not going to be run as part of the build process, and the whole build directory (which includes this cache directory) frequently gets removed entirely.

So we're looking for a way to allow rm -rf to work on the $GOPATH/pkg/mod directory while still blocking tests from being able to write files to this directory? The two seem mutually exclusive to me unfortunately, hence suggesting the manual flag.

(As an aside, happy to do the PR for this if it's acceptable)

@agnivade
Copy link
Contributor

Marking it as a proposal.

@agnivade agnivade changed the title cmd/go: Build argument to disable readonly $GOPATH/pkg/mod proposal: cmd/go: build argument to disable readonly $GOPATH/pkg/mod Apr 17, 2019
@gopherbot gopherbot added this to the Proposal milestone Apr 17, 2019
@bcmills
Copy link
Contributor

bcmills commented Apr 19, 2019

You can already run chmod u+w -R $GOPATH/pkg/mod or go clean -modcache explicitly before cleaning up.

Why would an explicit argument be more helpful than an explicit command? Seems like you have to update your configuration either way.

@bcmills bcmills added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Apr 19, 2019
@pbrkr
Copy link

pbrkr commented Apr 29, 2019

@bcmills: The problem for us is that we can't modify our CI system to run those commands at the start of a build. The fault here is 100% with the golang compiler, it has no valid case for removing the write bit from files & directories in the build tree.

Running git clean -xffd (which the CI system does) should be sufficient to fully clean up a build directory.

@bcmills bcmills removed the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Apr 29, 2019
@bcmills
Copy link
Contributor

bcmills commented Apr 29, 2019

@paul-betafive, how are you able to add arguments to the go command but not able to add a chmod or go clean command? Could you give some more detail on the specifics of your CI system?

@bcmills bcmills added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Apr 29, 2019
@pbrkr
Copy link

pbrkr commented Apr 29, 2019

We can add a chmod command after the go build command but that isn't water-tight as the build may fail or crash during go build after directories have already been marked as read-only. If the build server loses power or has a hard crash during go build then no error handling code will be able to run the chmod command.

We're using GitLab CI which unconditionally uses git clean after checkout to remove old build files. There's no option to add commands between the checkout and the clean.

@bcmills bcmills removed the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label May 7, 2019
@bcmills
Copy link
Contributor

bcmills commented May 7, 2019

We're using GitLab CI which unconditionally uses git clean after checkout to remove old build files. There's no option to add commands between the checkout and the clean.

Wait, why is your module cache in the same git repository as the thing you're testing in CI? That seems like a very unusual configuration, and if you split the two it would be a lot easier to decouple the go clean -modcache or chmod from the go build or git clean step.

@bcmills bcmills added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label May 7, 2019
@Psykar
Copy link
Author

Psykar commented May 9, 2019

@bcmills In my case at least it's not - buildroot (for example) build's it's output in a subdirectory of the repo however (which is under .gitignore)
Builds need to be reproducable without relying on any system packages (part of the build process will download golang source, compile and install it to a subdirectory, then use this installation for compiling the actual go packages which trigger this issue)

Having the module cache exist outside of the build directory means the build can potentially be affected by code outside of the repository.

For CI to a certain extend I agree that having the module cache actually be cached across builds makes a certain amount of sense.
But for buildroot (and similar) use case it does not.

FWIW the other side of the fence doesn't want to have to add a new command to their Makefile's specifically to handle a single package (golang) doing this.
http://lists.busybox.net/pipermail/buildroot/2019-April/248069.html

I'd like to find somewhere in the middle if possible!

@rsc
Copy link
Contributor

rsc commented May 28, 2019

This has come up enough that I think we should do something. There are good reasons for the default, but there are good reasons to be able to override it too. I suggest -pkgmodrw. CI systems can do things like export GOFLAGS=-pkgmodrw before their usual go commands.

/cc @bcmills @jayconrod

@bcmills bcmills removed the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label May 29, 2019
@bcmills bcmills modified the milestones: Proposal, Go1.14 May 29, 2019
@bcmills bcmills added the NeedsFix The path to resolution is known, but the work has not been done. label May 29, 2019
@bcmills
Copy link
Contributor

bcmills commented May 29, 2019

I'm a little reluctant to put -pkgmod right there in the flag name, since it's conceivable that we'll want to move the package cache somewhere (outside of GOPATH?) in a future release.

That said, I'm still not sure why export GOFLAGS=-pkgmodrw is particularly better than go clean -modcache: either way, you end up needing to inject some sort of declaration at the start of the build.

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

bcmills commented Jun 14, 2019

@jasonkeene, as noted in #31481 (comment) I think the execution bit is an easier win. Would you mind filing a separate issue for that?

@bcmills
Copy link
Contributor

bcmills commented Oct 18, 2019

Regarding the flag name: I would prefer something that does not assume that the path to the module cache always contains the string pkg/mod. At some point, we may want to change the location of the module cache or make it configurable (as in #34527).

So I would really rather we find a name other than -pkgmodrw.

How about -modcacherw, or perhaps -modcachemask=0777?

@rsc
Copy link
Contributor

rsc commented Oct 18, 2019

-modcacherw is fine. Let's not bring Unix mode bits into this.

@bcmills bcmills self-assigned this Oct 18, 2019
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/202079 mentions this issue: cmd/go: add a flag to avoid creating unwritable directories in the module cache

@zx2c4
Copy link
Contributor

zx2c4 commented Oct 21, 2019

Thank you for working on this. Having to chmod things is indeed a huge hassle and sometimes not available in all build systems.

Does this mean I'll need to pass -modcacherw to both go get and go build invocations, just in case the latter invokes the former? If so, would we be better served by making this nob into an environment variable?

@thepudds
Copy link
Contributor

thepudds commented Oct 21, 2019

If so, would we be better served by making this nob into an environment variable?

My expectation/ guess is export GOFLAGS=... would work for you once this is merged:

https://golang.org/cmd/go/#hdr-Environment_variables

@bcmills
Copy link
Contributor

bcmills commented Oct 21, 2019

Exactly: we expect that it will generally be used in conjunction with GOFLAGS.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/202563 mentions this issue: cmd/go: support -modcacherw in 'go mod' subcommands

gopherbot pushed a commit that referenced this issue Oct 22, 2019
The -modcacherw flag is now registered in work.AddModCommonFlags,
which is called from work.AddBuildFlags, where it was registered
before. 'go mod' subcommands register the flag by calling
work.AddModCommonFlags directly.

Also, build commands now exit with an error if -modcacherw is set
explicitly (not in GOFLAGS) in GOPATH mode.

Updates #31481

Change-Id: I461e59a51ed31b006fff4d5c57c2a866be0bbf38
Reviewed-on: https://go-review.googlesource.com/c/go/+/202563
Run-TryBot: Jay Conrod <[email protected]>
TryBot-Result: Gobot Gobot <[email protected]>
Reviewed-by: Bryan C. Mills <[email protected]>
derekmarcotte added a commit to prometheus-community/kitefactory that referenced this issue Feb 18, 2020
uqs pushed a commit to freebsd/freebsd-ports that referenced this issue Mar 2, 2020
…aded by gomod-vendor

Use module cache local to the WRKDIR and add the -modcacherw flag (available in
go1.14 [1, 2]) to instruct go mod vendor to leave directories in the module
cache read-write instead of making them unwritable.

[1] golang/go#31481
[2] https://go-review.googlesource.com/c/go/+/202079/

Reviewed by:	swills
Differential Revision:	https://reviews.freebsd.org/D23063


git-svn-id: svn+ssh://svn.freebsd.org/ports/head@527631 35697150-7ecd-e111-bb59-0022644237b5
uqs pushed a commit to freebsd/freebsd-ports that referenced this issue Mar 2, 2020
…aded by gomod-vendor

Use module cache local to the WRKDIR and add the -modcacherw flag (available in
go1.14 [1, 2]) to instruct go mod vendor to leave directories in the module
cache read-write instead of making them unwritable.

[1] golang/go#31481
[2] https://go-review.googlesource.com/c/go/+/202079/

Reviewed by:	swills
Differential Revision:	https://reviews.freebsd.org/D23063
Jehops pushed a commit to Jehops/freebsd-ports-legacy that referenced this issue Mar 2, 2020
…aded by gomod-vendor

Use module cache local to the WRKDIR and add the -modcacherw flag (available in
go1.14 [1, 2]) to instruct go mod vendor to leave directories in the module
cache read-write instead of making them unwritable.

[1] golang/go#31481
[2] https://go-review.googlesource.com/c/go/+/202079/

Reviewed by:	swills
Differential Revision:	https://reviews.freebsd.org/D23063


git-svn-id: svn+ssh://svn.freebsd.org/ports/head@527631 35697150-7ecd-e111-bb59-0022644237b5
ericbsd pushed a commit to ghostbsd/ghostbsd-ports that referenced this issue Mar 7, 2020
…aded by gomod-vendor

Use module cache local to the WRKDIR and add the -modcacherw flag (available in
go1.14 [1, 2]) to instruct go mod vendor to leave directories in the module
cache read-write instead of making them unwritable.

[1] golang/go#31481
[2] https://go-review.googlesource.com/c/go/+/202079/

Reviewed by:	swills
Differential Revision:	https://reviews.freebsd.org/D23063
@golang golang locked and limited conversation to collaborators Oct 21, 2020
@rsc rsc unassigned bcmills Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Proposal
Projects
None yet
Development

No branches or pull requests