asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Maxon <>
Subject Re: Proposal for alteration of criteria for automatic patch verification
Date Thu, 14 Jan 2016 00:07:34 GMT
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 <> 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 <> 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

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