Skip to content

x/build/cmd/coordinator: use --no-cache on docker build commands #20936

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

Closed
cybrcodr opened this issue Jul 7, 2017 · 6 comments
Closed

x/build/cmd/coordinator: use --no-cache on docker build commands #20936

cybrcodr opened this issue Jul 7, 2017 · 6 comments
Labels
Builders x/build issues (builders, bots, dashboards) FrozenDueToAge
Milestone

Comments

@cybrcodr
Copy link
Contributor

cybrcodr commented Jul 7, 2017

This is related to issue #20747 . I think @bradfitz is unable to reproduce the issue due to docker builds using cache. Use --no-cache to guarantee that steps are done fresh.

I think we may need to do this for other binaries as well.

@bradfitz
Copy link
Contributor

bradfitz commented Jul 7, 2017

I'd really rather not use --no-cache. The speed is nice.

I'd rather fix it by specifying the exact hash of all deps, including transitive ones.

@bradfitz bradfitz changed the title build/cmd/coordinator: use --no-cache on docker build commands x/build/cmd/coordinator: use --no-cache on docker build commands Jul 7, 2017
@gopherbot gopherbot added this to the Unreleased milestone Jul 7, 2017
@gopherbot gopherbot added the Builders x/build issues (builders, bots, dashboards) label Jul 7, 2017
@cybrcodr
Copy link
Contributor Author

cybrcodr commented Jul 7, 2017

How about if I make it an optional variable to be passed in?

Default w/o --no-cache param ...
$ make build0

To force --no-cache param ...
$ make build0 NO_CACHE=1

Wdyt?

@bradfitz
Copy link
Contributor

bradfitz commented Jul 7, 2017

I do not want a --fast vs a --correct flag. That's the wrong knob to give a user.

In the Gerrit CL you wrote:

There's definitely no one correct way to go about this with current approach.

But I think there is a correct approach. We can ask Go to give us the transitive list of deps (go list -f '{{.Deps}}' golang.org/x/build/cmd/coordinator) and then mark all their hashes in the Dockerfile.

I'll write a little tool.

@cybrcodr
Copy link
Contributor Author

cybrcodr commented Jul 8, 2017

Fair enough.

But I think there is a correct approach. We can ask Go to give us the transitive list of deps (go list -f '{{.Deps}}' golang.org/x/build/cmd/coordinator) and then mark all their hashes in the Dockerfile.

What I meant to say is that if we use the current approach of manually doing a go get of only a few packages and reset at the repo for some, it becomes arbitrary on which packages you choose to pin vs not.

Agree that it requires a tool to pin all dependencies down.

@cybrcodr
Copy link
Contributor Author

cybrcodr commented Jul 8, 2017

Closing this as it's better to use a tool for version pinning and not having to switch between cache and no cache.

@cybrcodr cybrcodr closed this as completed Jul 8, 2017
@bradfitz
Copy link
Contributor

FTR, little tool was in https://go-review.googlesource.com/c/47971/

@golang golang locked and limited conversation to collaborators Jul 12, 2018
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
Projects
None yet
Development

No branches or pull requests

3 participants