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]

Reply via email to