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 <vvo...@gmail.com> 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&utm_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
