Yes, that was the problem. We were building with CGO_ENABLED=0, which was
meaning that built-in packages like "os/user" were always stale and causing
rebuilds of almost every other package.
Putting this in my dockerfile (along with mounting the pkg directory as a
volume shared between each build) fixed the problem:
# Disable cgo so that binaries we build will be fully static.
ENV CGO_ENABLED=0
# Recompile the standard library with cgo disabled. This prevents the
standard library from being
# marked stale, causing full rebuilds every time.
RUN go install -v std
-Shaun
On Friday, December 9, 2016 at 1:51:15 PM UTC, sh...@tigera.io wrote:
>
> Thanks, that's given me a great thread to pull on. All the rebuilds track
> back to os/user being stale due to build ID mismatch. Probably an issue
> with the specific configuration we've set up for our build being different
> to the pre-build os/user (I think we disable CGO, for one). Should be able
> to figure it out from here.
>
> -Shaun
>
> On Thursday, December 8, 2016 at 8:49:43 PM UTC, Ian Lance Taylor wrote:
>>
>> On Thu, Dec 8, 2016 at 10:13 AM, <sh...@tigera.io> wrote:
>> > I've started with a clean pkg dir.
>> >
>> > It's odd; the mtimes look correct (same inside/outside container). the
>> > "buildid" to the compile commands s the same on each run too.
>> >
>> > Does anyone know if there's a way to print out the "StaleReason" that
>> the
>> > code collects, that might help me find out what gate I'm failing.
>>
>> go list -f '{{.StaleReason}}'
>>
>> Ian
>>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
