Hi, > 1. Is anyone else knows about these failures?
"these failures" means that the Travis CI jobs aren't ran, right? (It doesn't mean that the Travis CI jobs reports "failure".) This may be a Travis CI bug. > 2. Should we look into disabling these checks for PRs that only touch rust > code? I can do this, but am not sure of the history One approach is adding "[travis skip]" to commit message. We can't use path based conditional build on Travis CI because Travis CI doesn't provide the feature. See also: * https://docs.travis-ci.com/user/conditions-v1 * https://docs.travis-ci.com/user/conditions-testing Thanks, -- kou In <cafhtnrwxof+5a6jsubeubeq-ulw3skvlfrhfyqr1r7crahv...@mail.gmail.com> "Travis CI jobs gummed up on Arrow PRs?" on Sun, 15 Nov 2020 07:55:27 -0500, Andrew Lamb <al...@influxdata.com> wrote: > Sorry if this has already been discussed. > > There seems to be something wrong with the Travis CI jobs on some Arrow PRs > -- for example, > https://github.com/apache/arrow/pull/8662/checks?check_run_id=1400052607. > They go into the "pending" state and never seem to actually run. > > Since these appear to be checks of the C++ implementation on s390 or ARM, > which aren't relevant to the Rust implementation, it isn't really blocking > anything. > > I am wondering > 1. Is anyone else knows about these failures? > 2. Should we look into disabling these checks for PRs that only touch rust > code? I can do this, but am not sure of the history > > Thank you, > Andrew > > p.s. here is another example of a non rust PR that seems to show the same > issue: > https://github.com/apache/arrow/pull/8647 > > p.p.s. Here is a screenshot showing the travis CI UI for such a gummed up > test > > [image: Screen Shot 2020-11-15 at 7.50.27 AM.png]