asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ildar Absalyamov <>
Subject Re: Proposal for alteration of criteria for automatic patch verification
Date Wed, 13 Jan 2016 23:42:14 GMT
It would be really nice to break Jenkins test build into two stage process: ‘mvn test’
on each patch set submission and ‘mvn verify’ after the patch received +2 and got merged
into Gerrit, BUT before it got merged to ASF repo. Although I am not sure what should be done
in a case when the latter build does not pass, since it’s already merged into Gerrit and
we cannot revert that.

> On Jan 13, 2016, at 15:34, 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

Best regards,

View raw message