 we know how we were able to land the code on the bot if it doesn't even compile ?
<mattyw> jam, no idea, I pinged mgz to see if the logs can tell us any more
<mattyw> jam, this is the offending merge: http://juju-ci.vapour.ws:8080/job/github-merge-juju/1080/console but it shows the context test as passing. Then it fails in the next merge http://juju-ci.vapour.ws:8080/job/github-merge-juju/1081/console
<jam> mattyw: what is really strange is that it is failing inside "cmd/juju" how would that even have visibility into worker/uniter/context/factory_test.go
<mattyw> jam, there's something odd happening there, because the line that contains uniter/context correctly states the build failed - just the build errors are nowhere near it
<rogpeppe> review appreciated on this change that makes it possible to use Go 1.4 with our testing stuff: https://github.com/juju/testing/pull/36
<mattyw> jam, that must just be a bug with the way output is captured
<jam> mattyw: it may be a stderr vs stdout buffering issue
<jam> (stdout is oftend buffered and stderr is immediate)
<mattyw> jam, sounds most likely
<jam> though you have 300s from the time of that error messages and when it gets to uniter build failed, but I guess it isn't that many lines
<jam> mattyw: I think we need someone investigating this, but I'm at a loss for any more information myself
<jam> this feels a *lot* like we can't trust our bot to reject bad patches, which is a bad place to be
 * jam away
<mattyw> jam, I don't really see how that could land at all. Maybe running tests with -a to force rebuilding all the packages might help?
<mattyw> jam, that's all I can think of
<jam> mattyw: yeah, I just did a checkout of 2224d55 and it clearly doesn't "go test" here.
<mattyw> jam, it clearly shows it passing in the log of the merge
<mattyw> jam, even though we know it doesn't
<jam> mattyw: ok  	github.com/juju/juju/worker/uniter/context	17.402s yeah
<jam> mattyw: this feels a *lot* like we were running the tests on raw "master" rather than the merge of "master" and the 