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 <[email protected]> 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, Ildar
