Re: Static Analysis tests

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

Re: Static Analysis tests

> > 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

Re: Static Analysis tests

On Tue, May 3, 2016 at 2:47 AM John Meinel wrote: > Interestingly, putting it in "verify.sh" does have some fallout as well. > At least on my machines verify is already slow enough to cause github to > timeout while I'm pushing revisions. So I actually have to run it

Re: Static Analysis tests

On Mon, May 2, 2016 at 10:10 PM Nate Finch wrote: > I think it's a good point that we may only want to run some tests once, > not once per OS/Arch. However, I believe these particular tests are still > limited in scope by the OS/arch of the host machine. The go/build

Re: Backwards incompatible change to config.changed states

I'll have to check with Jorge Castro, but I imagine either the 13th or 27th of this month. I'll confirm and this will likely be a "Europe" friendly time. Marco On Mon, May 2, 2016 at 5:19 PM Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > Great suggestion, Marco! When would the next

Re: Backwards incompatible change to config.changed states

Great suggestion, Marco! When would the next office hour be? 2016-05-02 23:13 GMT+02:00 Marco Ceppi : > Might I suggest we do a hangout on air so we can record the discussion > while skipping the back and forth on the list? Possibly during an office > hour? > > Also,

Re: Backwards incompatible change to config.changed states

Might I suggest we do a hangout on air so we can record the discussion while skipping the back and forth on the list? Possibly during an office hour? Also, I'm not sure the decision is final and I certainly appreciate your feedback and welcome the continued discussion so we can reach a consensus!

Re: adding unit tests that take a long time

My 2c just so people know where I stand. I'm not in favour of skipping any tests by default. If people want to add flags so they can run subsets of tests, all credit to them, but I feel that it is just test noise. Making it too easy to skip long "unit" tests makes the problem too easy to ignore

Re: Backwards incompatible change to config.changed states

Merlijn, Apologies for the delayed reply. I realized that I had typed this up but forgotten to actually send it. You're right that there are still cases where the hook-persistent nature of the config.changed states continue to cause problems. However, after some discussion with Ben, I actually

Re: Static Analysis tests

Interestingly, putting it in "verify.sh" does have some fallout as well. At least on my machines verify is already slow enough to cause github to timeout while I'm pushing revisions. So I actually have to run it manually, and then git push --no-verify if I actually want it to complete. Adding 16s

Re: Static Analysis tests

I think it's a good point that we may only want to run some tests once, not once per OS/Arch. However, I believe these particular tests are still limited in scope by the OS/arch of the host machine. The go/build package respects the build tags in files, so in theory, one run of this on Ubuntu

Re: adding unit tests that take a long time

On Thu, Apr 28, 2016 at 11:44 PM Anastasia Macmood < anastasia.macm...@canonical.com> wrote: > I understand your desire for a quick turn around. > But I question the value that you would get from running "fast" (short) > tests - would this set include some fast running unit tests, integration >