Re: Travis CI improvements

[Kunal Khatua]

Thanks for the clarification, Vova !

With the Maven (M2) cache, if your numbers have dropped that low.. it should be 
fine. I was concerned because TravisCI gets kicked off almost instantaneously 
when a commit gets pushed to my private repo, and I didn't want to increase the 
burden on the CI system if I am frequently making checkins that are, say, UI/UX 
related.

~ Kunal
On 2/11/2019 1:12:06 AM, Vova Vysotskyi  wrote:
Thanks for the proposal, but I think enabling build only when changes in
.proto files wouldn't help, since changes may be accidentally done in the
corresponding java or c++ classes. Adding check for changes in the specific
list of java/c++ files also may not help, since in future may be added new
protobuf files, and that list should be updated every time.

Update: since it was a new job, the m2 cache wasn't used, so for now this
job takes less than 13 minutes and job with unit tests takes less than 28
minutes.

Also, most of the time in a new job is spent on just building Drill (less
than 8 minutes), regenerating java protobuf classes takes 9+ seconds and
regenerating c++ classes is also too fast. Time spent on installing
dependencies protobuf regeneration is about 3 minutes. One minute for
storing the cache and the rest of the time perhaps required for preparing
the machine.

Kind regards,
Volodymyr Vysotskyi


On Fri, Feb 8, 2019 at 8:14 PM Kunal Khatua wrote:

> Very useful, Vova! Thanks.
>
> Does the protobuf regeneration run always or is it conditional to
> detecting changes in the protobuf files? It might be worth testing for
> changes to .proto files before attempting to regenerate the Java and C++
> protobuf files. Otherwise, you'd be increasing the effective runtime on
> Travis by 50% all across the commits (incl those unrelated to protobuf).
>
> ~ Kunal
> On 2/8/2019 3:36:06 AM, Vova Vysotskyi wrote:
> Hi all,
>
> Recently there are more PRs which require changes in protobuf files, but
> sometimes contributors may forget to regenerate them. It was the reason for
> creating DRILL-7031 .
>
> Before the fix for this Jira, there was a single job which builds Drill,
> checks licenses and runs unit tests.
> In the fix for this Jira, this job was splitted into two jobs: the first
> one only runs unit tests and the second one builds Drill, checks the
> licenses and regenerates both Java and C++ protobuf files. For the case, if
> after regeneration changes are found, job will fail.
>
> So time required for finishing Travis job is reduced to 29 minutes (time of
> the longest job), but total time for both jobs exceeds current (was 32
> mins, but now 29+15 mins). Current build bay be found here:
>
> https://travis-ci.org/apache/drill/builds/490483425?utm_source=github_status_medium=notification
>
> Except for the check for changes in protobuf files, in the case of failure
> will be printed diff for changed classes which may be copied and applied as
> a patch. Build with the failed protobuf check may be found here:
> https://travis-ci.org/vdiravka/drill/jobs/490016316.
>
> Kind regards,
> Volodymyr Vysotskyi
>

Re: Travis CI improvements

[Vova Vysotskyi]

Thanks for the proposal, but I think enabling build only when changes in
.proto files wouldn't help, since changes may be accidentally done in the
corresponding java or c++ classes. Adding check for changes in the specific
list of java/c++ files also may not help, since in future may be added new
protobuf files, and that list should be updated every time.

Update: since it was a new job, the m2 cache wasn't used, so for now this
job takes less than 13 minutes and job with unit tests takes less than 28
minutes.

Also, most of the time in a new job is spent on just building Drill (less
than 8 minutes), regenerating java protobuf classes takes 9+ seconds and
regenerating c++ classes is also too fast. Time spent on installing
dependencies protobuf regeneration is about 3 minutes. One minute for
storing the cache and the rest of the time perhaps required for preparing
the machine.

Kind regards,
Volodymyr Vysotskyi


On Fri, Feb 8, 2019 at 8:14 PM Kunal Khatua  wrote:

> Very useful, Vova! Thanks.
>
> Does the protobuf regeneration run always or is it conditional to
> detecting changes in the protobuf files? It might be worth testing for
> changes to .proto files before attempting to regenerate the Java and C++
> protobuf files. Otherwise, you'd be increasing the effective runtime on
> Travis by 50% all across the commits (incl those unrelated to protobuf).
>
> ~ Kunal
> On 2/8/2019 3:36:06 AM, Vova Vysotskyi  wrote:
> Hi all,
>
> Recently there are more PRs which require changes in protobuf files, but
> sometimes contributors may forget to regenerate them. It was the reason for
> creating DRILL-7031 .
>
> Before the fix for this Jira, there was a single job which builds Drill,
> checks licenses and runs unit tests.
> In the fix for this Jira, this job was splitted into two jobs: the first
> one only runs unit tests and the second one builds Drill, checks the
> licenses and regenerates both Java and C++ protobuf files. For the case, if
> after regeneration changes are found, job will fail.
>
> So time required for finishing Travis job is reduced to 29 minutes (time of
> the longest job), but total time for both jobs exceeds current (was 32
> mins, but now 29+15 mins). Current build bay be found here:
>
> https://travis-ci.org/apache/drill/builds/490483425?utm_source=github_status_medium=notification
>
> Except for the check for changes in protobuf files, in the case of failure
> will be printed diff for changed classes which may be copied and applied as
> a patch. Build with the failed protobuf check may be found here:
> https://travis-ci.org/vdiravka/drill/jobs/490016316.
>
> Kind regards,
> Volodymyr Vysotskyi
>

Re: Travis CI improvements

[Kunal Khatua]

Very useful, Vova! Thanks.

Does the protobuf regeneration run always or is it conditional to detecting 
changes in the protobuf files? It might be worth testing for changes to .proto 
files before attempting to regenerate the Java and C++ protobuf files. 
Otherwise, you'd be increasing the effective runtime on Travis by 50% all 
across the commits (incl those unrelated to protobuf).

~ Kunal
On 2/8/2019 3:36:06 AM, Vova Vysotskyi  wrote:
Hi all,

Recently there are more PRs which require changes in protobuf files, but
sometimes contributors may forget to regenerate them. It was the reason for
creating DRILL-7031 .

Before the fix for this Jira, there was a single job which builds Drill,
checks licenses and runs unit tests.
In the fix for this Jira, this job was splitted into two jobs: the first
one only runs unit tests and the second one builds Drill, checks the
licenses and regenerates both Java and C++ protobuf files. For the case, if
after regeneration changes are found, job will fail.

So time required for finishing Travis job is reduced to 29 minutes (time of
the longest job), but total time for both jobs exceeds current (was 32
mins, but now 29+15 mins). Current build bay be found here:
https://travis-ci.org/apache/drill/builds/490483425?utm_source=github_status_medium=notification

Except for the check for changes in protobuf files, in the case of failure
will be printed diff for changed classes which may be copied and applied as
a patch. Build with the failed protobuf check may be found here:
https://travis-ci.org/vdiravka/drill/jobs/490016316.

Kind regards,
Volodymyr Vysotskyi

Re: Travis CI improvements

[Arina Yelchiyeva]

Great improvements. Thanks, Vova!

Kind regards,
Arina

> On Feb 8, 2019, at 1:35 PM, Vova Vysotskyi  wrote:
> 
> Hi all,
> 
> Recently there are more PRs which require changes in protobuf files, but
> sometimes contributors may forget to regenerate them. It was the reason for
> creating DRILL-7031 .
> 
> Before the fix for this Jira, there was a single job which builds Drill,
> checks licenses and runs unit tests.
> In the fix for this Jira, this job was splitted into two jobs: the first
> one only runs unit tests and the second one builds Drill, checks the
> licenses and regenerates both Java and C++ protobuf files. For the case, if
> after regeneration changes are found, job will fail.
> 
> So time required for finishing Travis job is reduced to 29 minutes (time of
> the longest job), but total time for both jobs exceeds current (was 32
> mins, but now 29+15 mins). Current build bay be found here:
> https://travis-ci.org/apache/drill/builds/490483425?utm_source=github_status_medium=notification
> 
> Except for the check for changes in protobuf files, in the case of failure
> will be printed diff for changed classes which may be copied and applied as
> a patch. Build with the failed protobuf check may be found here:
> https://travis-ci.org/vdiravka/drill/jobs/490016316.
> 
> Kind regards,
> Volodymyr Vysotskyi

Travis CI improvements

[Vova Vysotskyi]

Hi all,

Recently there are more PRs which require changes in protobuf files, but
sometimes contributors may forget to regenerate them. It was the reason for
creating DRILL-7031 .

Before the fix for this Jira, there was a single job which builds Drill,
checks licenses and runs unit tests.
In the fix for this Jira, this job was splitted into two jobs: the first
one only runs unit tests and the second one builds Drill, checks the
licenses and regenerates both Java and C++ protobuf files. For the case, if
after regeneration changes are found, job will fail.

So time required for finishing Travis job is reduced to 29 minutes (time of
the longest job), but total time for both jobs exceeds current (was 32
mins, but now 29+15 mins). Current build bay be found here:
https://travis-ci.org/apache/drill/builds/490483425?utm_source=github_status_medium=notification

Except for the check for changes in protobuf files, in the case of failure
will be printed diff for changed classes which may be copied and applied as
a patch. Build with the failed protobuf check may be found here:
https://travis-ci.org/vdiravka/drill/jobs/490016316.

Kind regards,
Volodymyr Vysotskyi