We got a response at https://travis-ci.community/t/s390x-jobs-are-stuck-in-the-received-state-for-days/10581/3?u=kiszk . Now, this problem has been solved.
An interesting comment in the post is as follow: > If you would like to have an increased build capacity, we are happy to discuss the plans with you. Please send email to supp...@travis-ci.com. Regards, Kazuaki Ishizaki From: Andrew Lamb <al...@influxdata.com> To: dev@arrow.apache.org Date: 2020/11/16 19:37 Subject: [EXTERNAL] Re: Travis CI jobs gummed up on Arrow PRs? Thank you! On Sun, Nov 15, 2020 at 8:30 PM Kazuaki Ishizaki <ishiz...@jp.ibm.com> wrote: > I have just reported this issue at the TravisCI forum. > > > https://travis-ci.community/t/s390x-jobs-have-not-been-almost-executed/10581 > > Regards, > Kazuaki Ishizaki, > > Sutou Kouhei <k...@clear-code.com> wrote on 2020/11/16 10:02:18: > > > From: Sutou Kouhei <k...@clear-code.com> > > To: dev@arrow.apache.org > > Date: 2020/11/16 10:02 > > Subject: [EXTERNAL] Re: Travis CI jobs gummed up on Arrow PRs? > > > > 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: > > > > * INVALID URI REMOVED > > > > u=https-3A__docs.travis-2Dci.com_user_conditions-2Dv1&d=DwICAg&c=jf_iaSHvJObTbx- > > siA1ZOg&r=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg&m=U4B_SrhIun- > > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE&s=iGmV- > > uUdAjCFprWPStYvU1jHvMt7D2YM8hmtdRLC4n4&e= > > * INVALID URI REMOVED > > > > u=https-3A__docs.travis-2Dci.com_user_conditions-2Dtesting&d=DwICAg&c=jf_iaSHvJObTbx- > > siA1ZOg&r=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg&m=U4B_SrhIun- > > > > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE&s=yO4rf79YYHbt8NJKOLGaCKMKUehCe_ub2RtpDLq06QA&e= > > > > > > 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, > > > INVALID URI REMOVED > > > > u=https-3A__github.com_apache_arrow_pull_8662_checks-3Fcheck-5Frun-5Fid-3D1400052607&d=DwICAg&c=jf_iaSHvJObTbx- > > siA1ZOg&r=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg&m=U4B_SrhIun- > > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE&s=V6iophseGVoYXwP1pLHBNtuMiHnEjT2bj69- > > iULRCZc&e= . > > > 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: > > > INVALID URI REMOVED > > u=https-3A__github.com_apache_arrow_pull_8647&d=DwICAg&c=jf_iaSHvJObTbx- > > siA1ZOg&r=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg&m=U4B_SrhIun- > > > > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE&s=lA3pYfzvwvn9bMYt2saPIQe5ZmC11vkGCPO8g6TyMMM&e= > > > > > > 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] > > > > >
