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 >>> >> >>
