add support for build caching #142
Conversation
|
Also, this is one of the few PRs I do want to keep as multiple commits, because it includes changes from multiple people. So the idea is to keep the number of commits low (under 5) and rebase-merge at the end. |
Maybe check the garbleMapHeaderName line in the ~/.cache directory? |
|
I think it's simpler than that, like I said on Slack - we could just check if |
mvdan
force-pushed
the
build-caching
branch
from
77d6dd3
to
fede6c4
Compare
|
This should now properly work with build IDs, including with Go master. Still lacks tests, though, which I'll add in the coming days. |
mvdan
changed the title
|
Alright, this now includes tests, a better commit message, and is ready for reviews. |
As per the discussion in golang/go#41145, it turns out that we don't need special support for build caching in -toolexec. We can simply modify the behavior of "[...]/compile -V=full" and "[...]/link -V=full" so that they include garble's own version and options in the printed build ID. The part of the build ID that matters is the last, since it's the "content ID" which is used to work out whether there is a need to redo the action (build) or not. Since cmd/go parses the last word in the output as "buildID=...", we simply add "+garble buildID=_/_/_/${hash}". The slashes let us imitate a full binary build ID, but we assume that the other components such as the action ID are not necessary, since the only reader here is cmd/go and it only consumes the content ID. The reported content ID includes the tool's original content ID, garble's own content ID from the built binary, and the garble options which modify how we obfuscate code. If any of the three changes, we should use a different build cache key. GOPRIVATE also affects caching, since a different GOPRIVATE value means that we might have to garble a different set of packages. Include tests, which mainly check that 'garble build -v' prints package lines when we expect to always need to rebuild packages, and that it prints nothing when we should be reusing the build cache even when the built binary is missing. After this change, 'go test' on Go 1.15.2 stabilizes at about 8s on my machine, whereas it used to be at around 25s before.
No description provided.