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:20:22 GMT
Agreed.  I'd vote for making sure that the broken daily test report be 
accompanied by a list of the changes that occurred since the last 
successful run - and that it be the responsibility of all folks with 
changes on that list to gang up and ensure that the problem is 
identified and resolved in a timely fashion.  We should probably spell 
out what that looks like, but it seems eminently reasonable....

On 1/13/16 4:03 PM, Chris Hillery wrote:
> +1 for Ian's initial proposal. This kind of pre-commit validation is always
> a balancing act between being comprehensive and being timely, and I think
> sticking with the distinction between "mvn test" and "mvn verify" is a
> clean and simple way to divide the tests.
>
> Given that pushing the Gerrit head to ASF is manual anyway, it wouldn't be
> TOO much headache to also enact Ildar's suggestion - basically, whoever
> does the ASF push would need to wait to ensure each commit passes the
> corresponding daily tests. However, IMHO at least this is probably not
> necessary. If a bug is uncovered in the daily tests, we'll need to push an
> additional commit to fix it, and that additional commit (plus the original
> buggy commit) will still end up on ASF anyway. And I worry a bit about
> anything that would cause the ASF Github mirror to stay out of sync with
> Gerrit for very long.
>
> Ceej
> aka Chris Hillery
>
> On Wed, Jan 13, 2016 at 3:42 PM, Ildar Absalyamov <
> ildar.absalyamov@gmail.com> 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 <imaxon@uci.edu> 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
>>
>>


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