True, doing it on every merge to master is also an option. I don't think we should try to discriminate based on which repo it was pushed to, though. If something were to be wrong I think the correct approach would not be to rewrite history. That just seems un-necessary, a revert commit should totally suffice.
On Wed, Jan 13, 2016 at 3:42 PM, Ildar Absalyamov < [email protected]> wrote: > 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 > >
