Re: [DISCUSS] Using Travis CI for Artemis PR builds
travis-ci uses GCE, which does not support ipv6 at all https://travis-ci.org/apache/activemq-artemis/builds/342667584#L975 :( 2018-02-17 10:33 GMT+05:00 Илья Шипицин : > Travis seems already performs "mvn install" by itself, we can reduce build > log (it's really huge) > > On Feb 16, 2018 10:46 PM, "Justin Bertram" wrote: > >> Artemis doesn't yet have AppVeyor integration. >> >> Perhaps you should open a JIRA or start a separate discussion thread about >> your JDBC issues. >> >> >> Justin >> >> On Fri, Feb 16, 2018 at 11:36 AM, Илья Шипицин >> wrote: >> >> > It turned out that ms SQL jdbc is not being tested (both documentation >> is >> > bad, SQL statements are also broken). Do you accept patches for app >> veyor >> > as well? >> > >> > On Feb 16, 2018 10:29 PM, "Justin Bertram" wrote: >> > >> > > We're discussing travis-ci.org [1]. >> > > >> > > >> > > Justin >> > > >> > > [1] https://travis-ci.org/apache/activemq-artemis >> > > >> > > On Fri, Feb 16, 2018 at 11:21 AM, Илья Шипицин >> > > wrote: >> > > >> > > > 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 > > >> > > > 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 >
Re: [DISCUSS] Using Travis CI for Artemis PR builds
Travis seems already performs "mvn install" by itself, we can reduce build log (it's really huge) On Feb 16, 2018 10:46 PM, "Justin Bertram" wrote: > Artemis doesn't yet have AppVeyor integration. > > Perhaps you should open a JIRA or start a separate discussion thread about > your JDBC issues. > > > Justin > > On Fri, Feb 16, 2018 at 11:36 AM, Илья Шипицин > wrote: > > > It turned out that ms SQL jdbc is not being tested (both documentation is > > bad, SQL statements are also broken). Do you accept patches for app veyor > > as well? > > > > On Feb 16, 2018 10:29 PM, "Justin Bertram" wrote: > > > > > We're discussing travis-ci.org [1]. > > > > > > > > > Justin > > > > > > [1] https://travis-ci.org/apache/activemq-artemis > > > > > > On Fri, Feb 16, 2018 at 11:21 AM, Илья Шипицин > > > wrote: > > > > > > > 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" > > > > > 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 > > > > 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 list
Re: [DISCUSS] Using Travis CI for Artemis PR builds
Artemis doesn't yet have AppVeyor integration. Perhaps you should open a JIRA or start a separate discussion thread about your JDBC issues. Justin On Fri, Feb 16, 2018 at 11:36 AM, Илья Шипицин wrote: > It turned out that ms SQL jdbc is not being tested (both documentation is > bad, SQL statements are also broken). Do you accept patches for app veyor > as well? > > On Feb 16, 2018 10:29 PM, "Justin Bertram" wrote: > > > We're discussing travis-ci.org [1]. > > > > > > Justin > > > > [1] https://travis-ci.org/apache/activemq-artemis > > > > On Fri, Feb 16, 2018 at 11:21 AM, Илья Шипицин > > wrote: > > > > > 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" > > > 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 > > > 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 > > > > 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 > > thin
Re: [DISCUSS] Using Travis CI for Artemis PR builds
It turned out that ms SQL jdbc is not being tested (both documentation is bad, SQL statements are also broken). Do you accept patches for app veyor as well? On Feb 16, 2018 10:29 PM, "Justin Bertram" wrote: > We're discussing travis-ci.org [1]. > > > Justin > > [1] https://travis-ci.org/apache/activemq-artemis > > On Fri, Feb 16, 2018 at 11:21 AM, Илья Шипицин > wrote: > > > 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" > > 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 > > 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 > > > > 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 > > > 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 > > > >>> > > > >> > > > >> > > > > > >
Re: [DISCUSS] Using Travis CI for Artemis PR builds
We're discussing travis-ci.org [1]. Justin [1] https://travis-ci.org/apache/activemq-artemis On Fri, Feb 16, 2018 at 11:21 AM, Илья Шипицин wrote: > 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" > 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 > 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 > > 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 > > 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 > > >>> > > >> > > >> > > >
Re: [DISCUSS] Using Travis CI for Artemis PR builds
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" 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 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 > 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 > 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 > >>> > >> > >> >
Re: [DISCUSS] Using Travis CI for Artemis PR builds
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 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 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 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 >>> >> >>
Re: [DISCUSS] Using Travis CI for Artemis PR builds
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 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 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 >> > >
Re: [DISCUSS] Using Travis CI for Artemis PR builds
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 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 >
Re: [DISCUSS] Using Travis CI for Artemis PR builds
> It looks like you've got your builds configured to use the same directory for all builds of the Jenkins job, rather than using a different directory for each build (5103, 5104, etc.)... I've looked through the build configuration and couldn't find anything specifically related to this. How would I know if the build is configured to use the same directory or not? Justin On Wed, Feb 14, 2018 at 11:08 PM, Tim Bain wrote: > I'm in no way trying to discourage you guys from evaluating Travis CI. > However... > > There are currently 4 builds that are in a failed state on the history of > that job: > >- >https://builds.apache.org/view/A/view/ActiveMQ/job/ > ActiveMQ-Artemis-PR-Build/5111/consoleFull >- Failed due to "Could not transfer artifact >com.google.code.maven-replacer-plugin:replacer:pom:1.5.3 from/to > central ( >https://repo.maven.apache.org/maven2): >/home/jenkins/.m2/repository/com/google/code/maven- > replacer-plugin/replacer/1.5.3/replacer-1.5.3.pom.part.lock >(No such file or directory)" - This might in fact be environmental, it's >hard to tell. >- >https://builds.apache.org/view/A/view/ActiveMQ/job/ > ActiveMQ-Artemis-PR-Build/5103/console >- Failed due to "failed to write new configuration file >/home/jenkins/jenkins-slave/workspace/ActiveMQ-Artemis-PR- > Build/.git/config.lock" >- It looks like you've got your builds configured to use the same > directory >for all builds of the Jenkins job, rather than using a different > directory >for each build (5103, 5104, etc.), and if that's true, it seems very >expected that concurrent builds would fail with errors like this one. Is >there a reason you're not checking out the code into a directory that's >specific to the individual build being done, to allow them to operate in >parallel without interfering with one another? Or am I misreading > something >about the log output? >- >https://builds.apache.org/view/A/view/ActiveMQ/job/ > ActiveMQ-Artemis-PR-Build/5104/consoleFull >- Failed due to checkstyle violations. Seems bona fide, and would not be >fixed by a move to Travis CI. >- >https://builds.apache.org/view/A/view/ActiveMQ/job/ > ActiveMQ-Artemis-PR-Build/5105/console >- Failed due to checkstyle violations. Seems bona fide, and would not be >fixed by a move to Travis CI. > > This is obviously a very small sample size, and you guys have been watching > these builds for far longer than the 10 minutes I've put into it just now, > so there's definitely a chance that today's builds aren't representative. > But do consider whether the "environmental" problems you're running into > with Jenkins are in fact Jenkins's doing, or whether maybe they're the > result of a misconfiguration that you'd have the power to fix yourselves. > Again, I'm not lobbying against considering Travis CI (I've got no > experience with it), just suggesting based on a very small sampling that > maybe some of the problems being laid at Jenkins' feet might not actually > be Jenkins's fault and might be solvable within Jenkins, so factor that > into any discussion of the pros and cons of moving vs. staying. > > Tim > > On Tue, Feb 13, 2018 at 3: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 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 > > >
Re: [DISCUSS] Using Travis CI for Artemis PR builds
I'm in no way trying to discourage you guys from evaluating Travis CI. However... There are currently 4 builds that are in a failed state on the history of that job: - https://builds.apache.org/view/A/view/ActiveMQ/job/ActiveMQ-Artemis-PR-Build/5111/consoleFull - Failed due to "Could not transfer artifact com.google.code.maven-replacer-plugin:replacer:pom:1.5.3 from/to central ( https://repo.maven.apache.org/maven2): /home/jenkins/.m2/repository/com/google/code/maven-replacer-plugin/replacer/1.5.3/replacer-1.5.3.pom.part.lock (No such file or directory)" - This might in fact be environmental, it's hard to tell. - https://builds.apache.org/view/A/view/ActiveMQ/job/ActiveMQ-Artemis-PR-Build/5103/console - Failed due to "failed to write new configuration file /home/jenkins/jenkins-slave/workspace/ActiveMQ-Artemis-PR-Build/.git/config.lock" - It looks like you've got your builds configured to use the same directory for all builds of the Jenkins job, rather than using a different directory for each build (5103, 5104, etc.), and if that's true, it seems very expected that concurrent builds would fail with errors like this one. Is there a reason you're not checking out the code into a directory that's specific to the individual build being done, to allow them to operate in parallel without interfering with one another? Or am I misreading something about the log output? - https://builds.apache.org/view/A/view/ActiveMQ/job/ActiveMQ-Artemis-PR-Build/5104/consoleFull - Failed due to checkstyle violations. Seems bona fide, and would not be fixed by a move to Travis CI. - https://builds.apache.org/view/A/view/ActiveMQ/job/ActiveMQ-Artemis-PR-Build/5105/console - Failed due to checkstyle violations. Seems bona fide, and would not be fixed by a move to Travis CI. This is obviously a very small sample size, and you guys have been watching these builds for far longer than the 10 minutes I've put into it just now, so there's definitely a chance that today's builds aren't representative. But do consider whether the "environmental" problems you're running into with Jenkins are in fact Jenkins's doing, or whether maybe they're the result of a misconfiguration that you'd have the power to fix yourselves. Again, I'm not lobbying against considering Travis CI (I've got no experience with it), just suggesting based on a very small sampling that maybe some of the problems being laid at Jenkins' feet might not actually be Jenkins's fault and might be solvable within Jenkins, so factor that into any discussion of the pros and cons of moving vs. staying. Tim On Tue, Feb 13, 2018 at 3: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 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 >
Re: [DISCUSS] Using Travis CI for Artemis PR builds
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 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
