asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Carey <dtab...@gmail.com>
Subject Re: Proposal for alteration of criteria for automatic patch verification
Date Thu, 14 Jan 2016 00:17:48 GMT
+100

It's too bad that Docker wouldn't give in - but - this is a long-overdue 
change to a more leveled testing approach, so I think now's a great time 
to make this change (i.e., this is a fine camel-back-breaking straw).

:-)

On 1/13/16 3:34 PM, Ian Maxon wrote:
> Hi all,
> I'd like to field the idea of changing the criteria we use to allow Jenkins
> to give +1 verified on patch sets. Right now, it runs 'mvn verify', which
> runs darn near about every test we have. While this was somewhat OK in the
> past, I think now, and going forward, it takes a long time, and it will
> only take longer as we make the integration tests more thorough.
>
> Additionally, I'd like to expand and re-enable the automated vagrant-based
> cluster integration tests, and unfortunately there isn't a simple way to
> make these work inside a docker container. I can get it to work by hand,
> but to make it automated I would have to fork or submit a patch to the
> Jenkins Docker cloud plugin, and it might not be a small or particularly
> clean/easy patch either.
>
> I'd like to change the goal that's run in the automatic tests on every
> commit to 'mvn test' rather than 'mvn verify'. This will still run all of
> the ExecutionTest(s), and the optimizer tests, and so on. It will stop the
> recovery tests and asterix installer tests from being run every time,
> however.
>
> However these tests are still certainly valuable, so I'd run them on a
> timer, perhaps daily, so that we would still catch bugs that these tests
> reveal rather promptly. Due to the fact we only commit a single digit
> number of times to master each day generally, the granularity of which
> commit will have introduced a bug will hopefully be rather low.
>
> Thoughts/comments?
>
> Thanks,
> -Ian
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message