activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Илья Шипицин <chipits...@gmail.com>
Subject Re: [DISCUSS] Using Travis CI for Artemis PR builds
Date Sat, 17 Feb 2018 05:33:11 GMT
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" <jbertram@apache.org> 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, Илья Шипицин <chipitsine@gmail.com>
> 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" <jbertram@apache.org> 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, Илья Шипицин <chipitsine@gmail.com>
> > > 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.gemmell@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 <jbertram@apache.org>
> > > > wrote:
> > > > > > I may have spoken too soon.  The UI on the Travis website
> > apparently
> > > > > takes
> > > > > > awhile to update or got out of sync or something.  The PR build
> > looks
> > > > to
> > > > > be
> > > > > > taking around 25 minutes consistently which I think is pretty
> good.
> > > > > >
> > > > > >
> > > > > > Justin
> > > > > >
> > > > > > On Thu, Feb 15, 2018 at 3:18 PM, Justin Bertram <
> > jbertram@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.pearce@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 <
> jbertram@apache.org>
> > > > > wrote:
> > > > > >>> >
> > > > > >>> > Over the last several months I've noticed that
the
> > Jenkins-based
> > > > > builds
> > > > > >>> > used to validate GitHub pull-requests for Artemis
are failing
> > at
> > > a
> > > > > >>> > significant rate for illegitimate reasons (e.g.
environmental
> > > > issues,
> > > > > >>> > timing out because they're too slow, etc.) or not
being run
> at
> > > all.
> > > > > >>> Even
> > > > > >>> > as I type this there are 4 PR builds listed on
> > > > > >>> https://builds.apache.org/
> > > > > >>> > which have been waiting for hours.
> > > > > >>> >
> > > > > >>> > I'd like to solve this problem so we have relatively
quick &
> > > > > reliable PR
> > > > > >>> > builds.  I'm vaguely familiar with Travis CI, and
I know
> other
> > > > Apache
> > > > > >>> > projects use it for PR builds.  I think it would
be worth
> > > > > investigating
> > > > > >>> > whether or not it would solve our problem.  What
do you guys
> > > think?
> > > > > >>> Does
> > > > > >>> > anybody in the community have experience with Travis
CI?
> > > > > >>> >
> > > > > >>> >
> > > > > >>> > Justin
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message