Re: Travis CI jobs gummed up on Arrow PRs?
Thanks for follow up. Reading between the lines this sounds like it was simply a capacity issue at Travis CI. And indeed, when I looked at the original job <https://github.com/apache/arrow/pull/8662/checks?check_run_id=1400052607> that I reported appeared to be stuck, it had indeed run (and failed as the upstream revision was gone). Thanks again for taking the time to look into this, Andrew On Wed, Nov 18, 2020 at 12:04 AM Kazuaki Ishizaki wrote: > 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 > 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 > 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 wrote on 2020/11/16 10:02:18: > > > > > From: Sutou Kouhei > > > 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=DwICAg=jf_iaSHvJObTbx- > > > siA1ZOg=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg=U4B_SrhIun- > > > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE=iGmV- > > > uUdAjCFprWPStYvU1jHvMt7D2YM8hmtdRLC4n4= > > > * INVALID URI REMOVED > > > > > > > > > u=https-3A__docs.travis-2Dci.com_user_conditions-2Dtesting=DwICAg=jf_iaSHvJObTbx- > > > siA1ZOg=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg=U4B_SrhIun- > > > > > > > > > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE=yO4rf79YYHbt8NJKOLGaCKMKUehCe_ub2RtpDLq06QA= > > > > > > > > > Thanks, > > > -- > > > kou > > > > > > In > > > > "Travis CI jobs gummed up on Arrow PRs?" on Sun, 15 Nov 2020 > 07:55:27 > > -0500, > > > Andrew Lamb 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=DwICAg=jf_iaSHvJObTbx- > > > siA1ZOg=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg=U4B_SrhIun- > > > > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE=V6iophseGVoYXwP1pLHBNtuMiHnEjT2bj69- > > > iULRCZc= . > > > > 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=DwICAg=jf_iaSHvJObTbx- > > > siA1ZOg=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg=U4B_SrhIun- > > > > > > > > > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE=lA3pYfzvwvn9bMYt2saPIQe5ZmC11vkGCPO8g6TyMMM= > > > > > > > > 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] > > > > > > > > > > > > >
RE: Travis CI jobs gummed up on Arrow PRs?
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 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 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 wrote on 2020/11/16 10:02:18: > > > From: Sutou Kouhei > > 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=DwICAg=jf_iaSHvJObTbx- > > siA1ZOg=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg=U4B_SrhIun- > > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE=iGmV- > > uUdAjCFprWPStYvU1jHvMt7D2YM8hmtdRLC4n4= > > * INVALID URI REMOVED > > > > u=https-3A__docs.travis-2Dci.com_user_conditions-2Dtesting=DwICAg=jf_iaSHvJObTbx- > > siA1ZOg=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg=U4B_SrhIun- > > > > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE=yO4rf79YYHbt8NJKOLGaCKMKUehCe_ub2RtpDLq06QA= > > > > > > Thanks, > > -- > > kou > > > > In > > "Travis CI jobs gummed up on Arrow PRs?" on Sun, 15 Nov 2020 07:55:27 > -0500, > > Andrew Lamb 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=DwICAg=jf_iaSHvJObTbx- > > siA1ZOg=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg=U4B_SrhIun- > > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE=V6iophseGVoYXwP1pLHBNtuMiHnEjT2bj69- > > iULRCZc= . > > > 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=DwICAg=jf_iaSHvJObTbx- > > siA1ZOg=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg=U4B_SrhIun- > > > > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE=lA3pYfzvwvn9bMYt2saPIQe5ZmC11vkGCPO8g6TyMMM= > > > > > > 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] > > > > >
Re: Travis CI jobs gummed up on Arrow PRs?
Thank you! On Sun, Nov 15, 2020 at 8:30 PM Kazuaki Ishizaki 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 wrote on 2020/11/16 10:02:18: > > > From: Sutou Kouhei > > 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=DwICAg=jf_iaSHvJObTbx- > > siA1ZOg=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg=U4B_SrhIun- > > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE=iGmV- > > uUdAjCFprWPStYvU1jHvMt7D2YM8hmtdRLC4n4= > > * INVALID URI REMOVED > > > > u=https-3A__docs.travis-2Dci.com_user_conditions-2Dtesting=DwICAg=jf_iaSHvJObTbx- > > siA1ZOg=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg=U4B_SrhIun- > > > > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE=yO4rf79YYHbt8NJKOLGaCKMKUehCe_ub2RtpDLq06QA= > > > > > > Thanks, > > -- > > kou > > > > In > > "Travis CI jobs gummed up on Arrow PRs?" on Sun, 15 Nov 2020 07:55:27 > -0500, > > Andrew Lamb 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=DwICAg=jf_iaSHvJObTbx- > > siA1ZOg=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg=U4B_SrhIun- > > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE=V6iophseGVoYXwP1pLHBNtuMiHnEjT2bj69- > > iULRCZc= . > > > 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=DwICAg=jf_iaSHvJObTbx- > > siA1ZOg=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg=U4B_SrhIun- > > > > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE=lA3pYfzvwvn9bMYt2saPIQe5ZmC11vkGCPO8g6TyMMM= > > > > > > 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] > > > > >
Re: Travis CI jobs gummed up on Arrow PRs?
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 wrote on 2020/11/16 10:02:18: > From: Sutou Kouhei > 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=DwICAg=jf_iaSHvJObTbx- > siA1ZOg=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg=U4B_SrhIun- > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE=iGmV- > uUdAjCFprWPStYvU1jHvMt7D2YM8hmtdRLC4n4= > * INVALID URI REMOVED > u=https-3A__docs.travis-2Dci.com_user_conditions-2Dtesting=DwICAg=jf_iaSHvJObTbx- > siA1ZOg=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg=U4B_SrhIun- > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE=yO4rf79YYHbt8NJKOLGaCKMKUehCe_ub2RtpDLq06QA= > > > Thanks, > -- > kou > > In > "Travis CI jobs gummed up on Arrow PRs?" on Sun, 15 Nov 2020 07:55:27 -0500, > Andrew Lamb 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=DwICAg=jf_iaSHvJObTbx- > siA1ZOg=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg=U4B_SrhIun- > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE=V6iophseGVoYXwP1pLHBNtuMiHnEjT2bj69- > iULRCZc= . > > 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=DwICAg=jf_iaSHvJObTbx- > siA1ZOg=b70dG_9wpCdZSkBJahHYQ4IwKMdp2hQM29f-ZCGj9Pg=U4B_SrhIun- > kKemWyzO5XUEZhrCIfFKnR967kBAI3rE=lA3pYfzvwvn9bMYt2saPIQe5ZmC11vkGCPO8g6TyMMM= > > > > 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] >
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: * https://docs.travis-ci.com/user/conditions-v1 * https://docs.travis-ci.com/user/conditions-testing Thanks, -- kou In "Travis CI jobs gummed up on Arrow PRs?" on Sun, 15 Nov 2020 07:55:27 -0500, Andrew Lamb 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]
Travis CI jobs gummed up on Arrow PRs?
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]
