Sorry for interrupting (joined mailing list to resolve some issues), are you talking about travis-ci.org or travis-ci.com?
On Feb 16, 2018 10:18 PM, "Robbie Gemmell" <robbie.gemm...@gmail.com> wrote: > I believe the mirrors in the apache github org have a shared resource > pool at Travis, while jobs for your personal forks run in the global > resource pool. Its not unusual for the latter to be quicker off the > mark, but even then its usually just seconds of difference. > Occasionally there can be a backlog from having really large jobs or > many jobs from other projects but typically its not been an issue for > long. Using Appveyor as well can help too as they tend not to be > backlogged at the same time and the additional env is useful in > itself. > > Robbie > > On 16 February 2018 at 16:00, Justin Bertram <jbert...@apache.org> wrote: > > I may have spoken too soon. The UI on the Travis website apparently > takes > > awhile to update or got out of sync or something. The PR build looks to > be > > taking around 25 minutes consistently which I think is pretty good. > > > > > > Justin > > > > On Thu, Feb 15, 2018 at 3:18 PM, Justin Bertram <jbert...@apache.org> > wrote: > > > >> Initial results are not encouraging. > >> > >> I got Apache infrastructure to enable Travis CI builds [1] after which I > >> disabled the current Jenkins-based PR build and sent a PR with the > >> necessary .travis.yml file to trigger a Travis CI build [2]. I had also > >> enabled Travis CI builds on my own GitHub repo so the Travis CI build > was > >> triggered on both the Apache PR as well as my own GitHub branch. After > an > >> hour I got an email saying the build for my personal GitHub branch > >> succeeded, but after almost an hour and a half the build for the Apache > CI > >> failed for no clear reason. Later I updated the PR branch and > performed a > >> push -f to trigger more builds. The build on my personal GitHub branch > >> finished without issue in about 20 minutes while the Apache PR build is > >> still waiting to actually start. > >> > >> This looks like a fail to me. > >> > >> > >> Justin > >> > >> [1] https://issues.apache.org/jira/browse/INFRA-16042 > >> [2] https://github.com/apache/activemq-artemis/pull/1872 > >> > >> On Tue, Feb 13, 2018 at 4:56 PM, Michael André Pearce < > >> michael.andre.pea...@me.com> wrote: > >> > >>> This is great idea! I get so frustrated with these environment issues. > >>> +100 > >>> > >>> Some other advantages I could see we could implement if successful. > >>> > >>> run a Linux build and a macOS build eg to check bits like kqueue and or > >>> other os specific behaviours (aio fallback to nio) > >>> > >>> look to use appveyor for a windows build validation. (I’m thinking this > >>> validates bat files etc and ensures not Linux specific paths being > used in > >>> code by mistake) > >>> > >>> Sent from my iPhone > >>> > >>> > On 14 Feb 2018, at 03:17, Justin Bertram <jbert...@apache.org> > wrote: > >>> > > >>> > Over the last several months I've noticed that the Jenkins-based > builds > >>> > used to validate GitHub pull-requests for Artemis are failing at a > >>> > significant rate for illegitimate reasons (e.g. environmental issues, > >>> > timing out because they're too slow, etc.) or not being run at all. > >>> Even > >>> > as I type this there are 4 PR builds listed on > >>> https://builds.apache.org/ > >>> > which have been waiting for hours. > >>> > > >>> > I'd like to solve this problem so we have relatively quick & > reliable PR > >>> > builds. I'm vaguely familiar with Travis CI, and I know other Apache > >>> > projects use it for PR builds. I think it would be worth > investigating > >>> > whether or not it would solve our problem. What do you guys think? > >>> Does > >>> > anybody in the community have experience with Travis CI? > >>> > > >>> > > >>> > Justin > >>> > >> > >> >
