[DISCUSS] Using Travis CI for Artemis PR builds

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] Using Travis CI for Artemis PR builds

jbertram
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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Using Travis CI for Artemis PR builds

MichaelAndrePearce
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Using Travis CI for Artemis PR builds

Tim Bain
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 <
[hidden email]> 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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Using Travis CI for Artemis PR builds

jbertram
> 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 <[hidden email]> 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 <
> [hidden email]> 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 <[hidden email]> 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
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Using Travis CI for Artemis PR builds

jbertram
In reply to this post by MichaelAndrePearce
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 <
[hidden email]> 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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Using Travis CI for Artemis PR builds

jbertram
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 <[hidden email]> 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 <
> [hidden email]> 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 <[hidden email]> 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
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Using Travis CI for Artemis PR builds

Robbie Gemmell
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 <[hidden email]> 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 <[hidden email]> 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 <
>> [hidden email]> 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 <[hidden email]> 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
>>>
>>
>>
Reply | Threaded
Open this post in threaded view
|

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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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 <
> >> [hidden email]> 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 <[hidden email]>
> 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
> >>>
> >>
> >>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Using Travis CI for Artemis PR builds

jbertram
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, Илья Шипицин <[hidden email]> 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" <[hidden email]>
> 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 <[hidden email]>
> 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 <[hidden email]>
> > 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 <
> > >> [hidden email]> 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 <[hidden email]>
> > 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
> > >>>
> > >>
> > >>
> >
>
Reply | Threaded
Open this post in threaded view
|

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" <[hidden email]> 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, Илья Шипицин <[hidden email]>
> 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" <[hidden email]>
> > 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 <[hidden email]>
> > 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 <[hidden email]
> >
> > > 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 <
> > > >> [hidden email]> 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 <[hidden email]>
> > > 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
> > > >>>
> > > >>
> > > >>
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Using Travis CI for Artemis PR builds

jbertram
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, Илья Шипицин <[hidden email]> 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" <[hidden email]> 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, Илья Шипицин <[hidden email]>
> > 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" <[hidden email]>
> > > 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 <[hidden email]>
> > > 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 <
> [hidden email]
> > >
> > > > 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 <
> > > > >> [hidden email]> 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 <[hidden email]>
> > > > 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
> > > > >>>
> > > > >>
> > > > >>
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

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" <[hidden email]> 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, Илья Шипицин <[hidden email]>
> 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" <[hidden email]> 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, Илья Шипицин <[hidden email]>
> > > 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" <[hidden email]
> >
> > > > 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 <[hidden email]>
> > > > 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 <
> > [hidden email]
> > > >
> > > > > 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 <
> > > > > >> [hidden email]> 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 <
> [hidden email]>
> > > > > 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
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

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 Илья Шипицин <[hidden email]>:

> 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" <[hidden email]> 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, Илья Шипицин <[hidden email]>
>> 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" <[hidden email]> 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, Илья Шипицин <[hidden email]>
>> > > 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" <
>> [hidden email]>
>> > > > 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 <[hidden email]
>> >
>> > > > 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 <
>> > [hidden email]
>> > > >
>> > > > > 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 <
>> > > > > >> [hidden email]> 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 <
>> [hidden email]>
>> > > > > 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
>> > > > > >>>
>> > > > > >>
>> > > > > >>
>> > > > >
>> > > >
>> > >
>> >
>>
>