On Tue, May 3, 2016 at 10:43 AM John Meinel wrote:
>
> >
> > We should investigate using go/build.Context.UseAllFiles to ignore the
> build tags. As long as there are no "//+build ignore" files lurking, and as
> long as we're not trying to do type-checking, that should be fine.
> >
>
> I'm curiou
>
> We should investigate using go/build.Context.UseAllFiles to ignore the
build tags. As long as there are no "//+build ignore" files lurking, and as
long as we're not trying to do type-checking, that should be fine.
>
I'm curious how this works. As often we use build flags to create a
different
is just
>>> academic until we need something that doesn't live in the Go ecosystem,
>>> though.
>>>
>>> Most importantly, I don't want to lose the ability to distinguish the
>>> types of tests. As an example: where we run static analysis s
here we run static analysis should never
>> matter, so we can cut a merge job short by performing all of the static
>> analysis checks up front. That doesn't matter much if we only gate merges
>> on running the tests on one Ubuntu series/arch; but what if we want to
>> star
short by performing all of the static
>> analysis checks up front. That doesn't matter much if we only gate merges
>> on running the tests on one Ubuntu series/arch; but what if we want to
>> start gating on Windows, CentOS, or additional architectures? It would not
>> make
> on running the tests on one Ubuntu series/arch; but what if we want to
> start gating on Windows, CentOS, or additional architectures? It would not
> make sense to run them all in parallel if they're all going to fail on the
> static analysis tests. And then if we've run the
y performing all of the static analysis
checks up front. That doesn't matter much if we only gate merges on running
the tests on one Ubuntu series/arch; but what if we want to start gating on
Windows, CentOS, or additional architectures? It would not make sense to
run them all in parallel if th
On Wed, Apr 27, 2016 at 9:14 PM, Nate Finch wrote:
> So, I don't really think the method of testing should determine where a test
> lives or how it is run. I could test the exact same things with a more
> common unit test - check the tls config we use when dialing the API is using
> tls 1.2, that
Maybe we're not as far apart as I thought at first.
My thought was that they'd live under github.com/juju/juju/devrules (or
some other name) and therefore only get run during a full test run or if
you run them there specifically. What is a full test run if not a test of
all our code? These tests
On Thu, Apr 28, 2016 at 11:14 AM Nate Finch
wrote:
> From the other thread:
>
> I wrote a test that parses the entire codebase under github.com/juju/juju to
> look for places where we're creating a new value of crypto/tls.Config
> instead of using the new helper function that I wrote that creates
>From the other thread:
I wrote a test that parses the entire codebase under github.com/juju/juju to
look for places where we're creating a new value of crypto/tls.Config
instead of using the new helper function that I wrote that creates one with
more secure defaults. It takes 16.5 seconds to run
11 matches
Mail list logo
