Re: Travis CI

[Till Rohrmann]

I'm in favour of splitting the project up into multiple repositories. This
will decrease building and testing time locally as well as on Travis. The
downside, however, will be that if not built together, conflicting changes
between different modules might go unnoticed until the release or the next
time someone commits to the respective sub repository.

Cheers,
Till

On Wed, Dec 14, 2016 at 4:44 PM, Henry Saputra 
wrote:

> Thanks for the insight, Robert.
>
> I have new MacbookPro so I think should have enough CPU to build.
>
> Seemed like the long time taken mostly on shading and pulling the world
> (dependencies)
>
> Do you have anything in your settings.xml to set the updatePolicy for
> central repo?
>
> - Henry
>
> On Wed, Dec 14, 2016 at 2:34 AM, Robert Metzger 
> wrote:
>
> > On my machine, I need ~10 minutes to do a clean install without tests.
> Not
> > sure what is causing the slow builds in your environment.
> > I think our builds are both IO (shading) and CPU (Scala compiler)
> > intensive. If one is not well equipped you'll have these build times.
> >
> > I contacted the Travis support to hear if there's anything we can do
> > regarding the time limit.
> >
> > On Wed, Dec 14, 2016 at 3:52 AM, Henry Saputra 
> > wrote:
> >
> > > Building Flink from root now takes long time due to more and more
> modules
> > > that we have =(
> > > For me if takes about 50 minutes or more when doing "mvn clean install
> > > -DskipTests"
> > >
> > > Should we start adding Maven profiles to help exclude some Maven
> modules,
> > > like connectors and flink-libraries by default ?
> > >
> > > Do you guys see the same behavior?
> > >
> > > - Henry
> > >
> > > On Thu, Nov 10, 2016 at 1:35 PM, Ufuk Celebi  wrote:
> > >
> > > > I also just noticed it today. We used to work with the 120 minutes
> > limit
> > > > and the builds took way longer as you said. I don't know what's going
> > on
> > > > here...
> > > >
> > > > It might be related to some issues they reported a few hours ago (
> > > > https://twitter.com/traviscistatus), but I can't tell.
> > > >
> > > > I really hope that the new env is temporary (although the reduced
> build
> > > > time is indeed nice ;)). Let's monitor this...
> > > >
> > > > – Ufuk
> > > >
> > > > On 10 November 2016 at 22:15:51, Greg Hogan (c...@greghogan.com)
> > wrote:
> > > > > We're getting the dreaded "The job exceeded the maximum time limit
> > for
> > > > > jobs, and has been terminated." error for some recent Travis-CI
> > builds.
> > > > > https://travis-ci.org/apache/flink/builds/174615801
> > > > >
> > > > > The docs state that termination will occur when "A job takes longer
> > > than
> > > > 50
> > > > > minutes on travis-ci.org", which applies to Flink as well as user
> > > GitHub
> > > > > accounts.
> > > > > https://docs.travis-ci.com/user/customizing-the-build/#
> > Build-Timeouts
> > > > >
> > > > > The jobs are running much faster now, as our builds have
> consistently
> > > > taken
> > > > > over an hour and up to an hour and a half. The following recently
> > > > > successful build looks to be a mix of fast and slow jobs.
> > > > > https://travis-ci.org/apache/flink/builds/174596630
> > > > >
> > > > > Greg
> > > > >
> > > >
> > > >
> > >
> >
>

Re: Travis CI

[Henry Saputra]

Thanks for the insight, Robert.

I have new MacbookPro so I think should have enough CPU to build.

Seemed like the long time taken mostly on shading and pulling the world
(dependencies)

Do you have anything in your settings.xml to set the updatePolicy for
central repo?

- Henry

On Wed, Dec 14, 2016 at 2:34 AM, Robert Metzger  wrote:

> On my machine, I need ~10 minutes to do a clean install without tests. Not
> sure what is causing the slow builds in your environment.
> I think our builds are both IO (shading) and CPU (Scala compiler)
> intensive. If one is not well equipped you'll have these build times.
>
> I contacted the Travis support to hear if there's anything we can do
> regarding the time limit.
>
> On Wed, Dec 14, 2016 at 3:52 AM, Henry Saputra 
> wrote:
>
> > Building Flink from root now takes long time due to more and more modules
> > that we have =(
> > For me if takes about 50 minutes or more when doing "mvn clean install
> > -DskipTests"
> >
> > Should we start adding Maven profiles to help exclude some Maven modules,
> > like connectors and flink-libraries by default ?
> >
> > Do you guys see the same behavior?
> >
> > - Henry
> >
> > On Thu, Nov 10, 2016 at 1:35 PM, Ufuk Celebi  wrote:
> >
> > > I also just noticed it today. We used to work with the 120 minutes
> limit
> > > and the builds took way longer as you said. I don't know what's going
> on
> > > here...
> > >
> > > It might be related to some issues they reported a few hours ago (
> > > https://twitter.com/traviscistatus), but I can't tell.
> > >
> > > I really hope that the new env is temporary (although the reduced build
> > > time is indeed nice ;)). Let's monitor this...
> > >
> > > – Ufuk
> > >
> > > On 10 November 2016 at 22:15:51, Greg Hogan (c...@greghogan.com)
> wrote:
> > > > We're getting the dreaded "The job exceeded the maximum time limit
> for
> > > > jobs, and has been terminated." error for some recent Travis-CI
> builds.
> > > > https://travis-ci.org/apache/flink/builds/174615801
> > > >
> > > > The docs state that termination will occur when "A job takes longer
> > than
> > > 50
> > > > minutes on travis-ci.org", which applies to Flink as well as user
> > GitHub
> > > > accounts.
> > > > https://docs.travis-ci.com/user/customizing-the-build/#
> Build-Timeouts
> > > >
> > > > The jobs are running much faster now, as our builds have consistently
> > > taken
> > > > over an hour and up to an hour and a half. The following recently
> > > > successful build looks to be a mix of fast and slow jobs.
> > > > https://travis-ci.org/apache/flink/builds/174596630
> > > >
> > > > Greg
> > > >
> > >
> > >
> >
>

Re: Travis CI

[Stephan Ewen]

I am starting to think that we should go a step further from "build
profiles".
How about splitting the repository up into multiple repositories that can
be built independently? We could for example do

  - flink-core (core, apis, runtime, clients)
  - flink-libraries (gelly, ml, cep, table, scala shell, python)
  - flink-connectors
  - flink-contrib

I think we should still retain one community and one PMC, so these would
not be sub-projects, but simply independently organized repositories and
build units, for better maintainability.

I am curious to hear what others think. If there are no strong concerns, I
would start a dedicated discussion thread about that after the 1.2 release.

Greetings,
Stephan

PS: We need a git wizard to help us migrate modules without loosing commit
history. I think it can work with some sophisticated "git filter-branch"
magic...



On Wed, Dec 14, 2016 at 11:34 AM, Robert Metzger 
wrote:

> On my machine, I need ~10 minutes to do a clean install without tests. Not
> sure what is causing the slow builds in your environment.
> I think our builds are both IO (shading) and CPU (Scala compiler)
> intensive. If one is not well equipped you'll have these build times.
>
> I contacted the Travis support to hear if there's anything we can do
> regarding the time limit.
>
> On Wed, Dec 14, 2016 at 3:52 AM, Henry Saputra 
> wrote:
>
> > Building Flink from root now takes long time due to more and more modules
> > that we have =(
> > For me if takes about 50 minutes or more when doing "mvn clean install
> > -DskipTests"
> >
> > Should we start adding Maven profiles to help exclude some Maven modules,
> > like connectors and flink-libraries by default ?
> >
> > Do you guys see the same behavior?
> >
> > - Henry
> >
> > On Thu, Nov 10, 2016 at 1:35 PM, Ufuk Celebi  wrote:
> >
> > > I also just noticed it today. We used to work with the 120 minutes
> limit
> > > and the builds took way longer as you said. I don't know what's going
> on
> > > here...
> > >
> > > It might be related to some issues they reported a few hours ago (
> > > https://twitter.com/traviscistatus), but I can't tell.
> > >
> > > I really hope that the new env is temporary (although the reduced build
> > > time is indeed nice ;)). Let's monitor this...
> > >
> > > – Ufuk
> > >
> > > On 10 November 2016 at 22:15:51, Greg Hogan (c...@greghogan.com)
> wrote:
> > > > We're getting the dreaded "The job exceeded the maximum time limit
> for
> > > > jobs, and has been terminated." error for some recent Travis-CI
> builds.
> > > > https://travis-ci.org/apache/flink/builds/174615801
> > > >
> > > > The docs state that termination will occur when "A job takes longer
> > than
> > > 50
> > > > minutes on travis-ci.org", which applies to Flink as well as user
> > GitHub
> > > > accounts.
> > > > https://docs.travis-ci.com/user/customizing-the-build/#
> Build-Timeouts
> > > >
> > > > The jobs are running much faster now, as our builds have consistently
> > > taken
> > > > over an hour and up to an hour and a half. The following recently
> > > > successful build looks to be a mix of fast and slow jobs.
> > > > https://travis-ci.org/apache/flink/builds/174596630
> > > >
> > > > Greg
> > > >
> > >
> > >
> >
>

Re: Travis CI

[Robert Metzger]

On my machine, I need ~10 minutes to do a clean install without tests. Not
sure what is causing the slow builds in your environment.
I think our builds are both IO (shading) and CPU (Scala compiler)
intensive. If one is not well equipped you'll have these build times.

I contacted the Travis support to hear if there's anything we can do
regarding the time limit.

On Wed, Dec 14, 2016 at 3:52 AM, Henry Saputra 
wrote:

> Building Flink from root now takes long time due to more and more modules
> that we have =(
> For me if takes about 50 minutes or more when doing "mvn clean install
> -DskipTests"
>
> Should we start adding Maven profiles to help exclude some Maven modules,
> like connectors and flink-libraries by default ?
>
> Do you guys see the same behavior?
>
> - Henry
>
> On Thu, Nov 10, 2016 at 1:35 PM, Ufuk Celebi  wrote:
>
> > I also just noticed it today. We used to work with the 120 minutes limit
> > and the builds took way longer as you said. I don't know what's going on
> > here...
> >
> > It might be related to some issues they reported a few hours ago (
> > https://twitter.com/traviscistatus), but I can't tell.
> >
> > I really hope that the new env is temporary (although the reduced build
> > time is indeed nice ;)). Let's monitor this...
> >
> > – Ufuk
> >
> > On 10 November 2016 at 22:15:51, Greg Hogan (c...@greghogan.com) wrote:
> > > We're getting the dreaded "The job exceeded the maximum time limit for
> > > jobs, and has been terminated." error for some recent Travis-CI builds.
> > > https://travis-ci.org/apache/flink/builds/174615801
> > >
> > > The docs state that termination will occur when "A job takes longer
> than
> > 50
> > > minutes on travis-ci.org", which applies to Flink as well as user
> GitHub
> > > accounts.
> > > https://docs.travis-ci.com/user/customizing-the-build/#Build-Timeouts
> > >
> > > The jobs are running much faster now, as our builds have consistently
> > taken
> > > over an hour and up to an hour and a half. The following recently
> > > successful build looks to be a mix of fast and slow jobs.
> > > https://travis-ci.org/apache/flink/builds/174596630
> > >
> > > Greg
> > >
> >
> >
>

Re: Travis CI

[Ufuk Celebi]

I also just noticed it today. We used to work with the 120 minutes limit and 
the builds took way longer as you said. I don't know what's going on here...

It might be related to some issues they reported a few hours ago 
(https://twitter.com/traviscistatus), but I can't tell.

I really hope that the new env is temporary (although the reduced build time is 
indeed nice ;)). Let's monitor this...

– Ufuk

On 10 November 2016 at 22:15:51, Greg Hogan (c...@greghogan.com) wrote:
> We're getting the dreaded "The job exceeded the maximum time limit for
> jobs, and has been terminated." error for some recent Travis-CI builds.
> https://travis-ci.org/apache/flink/builds/174615801
>  
> The docs state that termination will occur when "A job takes longer than 50
> minutes on travis-ci.org", which applies to Flink as well as user GitHub
> accounts.
> https://docs.travis-ci.com/user/customizing-the-build/#Build-Timeouts
>  
> The jobs are running much faster now, as our builds have consistently taken
> over an hour and up to an hour and a half. The following recently
> successful build looks to be a mix of fast and slow jobs.
> https://travis-ci.org/apache/flink/builds/174596630
>  
> Greg
>  

Re: Travis-CI builds queuing up

[Robert Metzger]

Now there is a blog post on the update:
https://blogs.apache.org/infra/entry/apache_gains_additional_travis_ci
It seems that Apache now has 30 concurrent builds and is a paying Travis
user/customer.

On Thu, Apr 2, 2015 at 3:58 PM, Robert Metzger rmetz...@apache.org wrote:

 I just found out that the execution time limit for the container-based
 infra (the one we're using) is 120 minutes ;)
 So we have some room left to write more test ;) (But please don't overdo
 it )

 On Tue, Mar 31, 2015 at 11:32 AM, Maximilian Michels m...@apache.org
 wrote:

 Very nice. Thanks Robert!

 On Mon, Mar 30, 2015 at 9:13 PM, Robert Metzger rmetz...@apache.org
 wrote:

  It seems that the issue is fixed. I've just pushed two times to a pull
  request and it immediately started building both.
  I think the apache user has much more parallel builds available now
 (we
  don't have any builds queuing up anymore).
 
  On Thu, Mar 26, 2015 at 4:06 PM, Henry Saputra henry.sapu...@gmail.com
 
  wrote:
 
   Awesome news!
  
   On Thursday, March 26, 2015, Robert Metzger rmetz...@apache.org
 wrote:
  
Travis replied me with very good news: Somebody from INFRA was
 asking
  the
same question around the same time as I did and Travis is working on
   adding
more build capacity for the apache github organization.
I hope we'll soon have quicker builds again.
   
On Tue, Mar 24, 2015 at 4:42 PM, Henry Saputra 
  henry.sapu...@gmail.com
javascript:;
wrote:
   
 That's good idea.

 Should be good to have mix of stable with Apache Jenkins for
 master
 and PRs, and Travis for individual forks.

 - Henry

 On Tue, Mar 24, 2015 at 8:03 AM, Maximilian Michels 
 m...@apache.org
javascript:;
 wrote:
  Hey!
 
  I would also like to continue using Travis but the current
  situation
   is
 not
  acceptable because we practically can't use Travis anymore for
 pull
  requests or the current master. If it cannot be resolved then I
  think
we
  should move on.
 
  The builds service team [1] at Apache offers Jenkins [2] for
   continuous
  integration. I think it should be fairly simple to set up. We
 could
still
  use Travis in our forked repositories but have a reliable CI
  solution
for
  the master and pull requests.
 
  Max
 
  [1] https://builds.apache.org/
  [2] http://jenkins-ci.org
 
  On Tue, Mar 24, 2015 at 3:46 PM, Márton Balassi 
 balassi.mar...@gmail.com javascript:;
  wrote:
 
  I also like the travis infrastucture. Thanks for bringing this
 up
   and
  reaching out to the travis guys.
 
  On Tue, Mar 24, 2015 at 3:38 PM, Robert Metzger 
   rmetz...@apache.org
javascript:;
  wrote:
 
   Hi guys,
  
   the build queue on travis is getting very very long. It seems
  that
it
  takes
   4 days now until commits to master are build. The nightly
 builds
from
 the
   website and the maven snapshots are also delayed by that.
   Right now,  there are 33 pull request builds scheduled (
   https://travis-ci.org/apache/flink/pull_requests), and 8
 builds
   on
  master:
   https://travis-ci.org/apache/flink/builds.
  
   The problem is that travis accounts are per github user. In
 our
case,
 the
   user is apache, so all ASF projects that have travis
 enabled
share 5
   concurrent builders.
  
   I would actually like to continue using Travis.
  
   The easiest option is probably asking travis if they can give
  the
  apache
   user more build capacity.
  
   If thats not possible, we have to look into other options.
  
  
   I'm going to ask Travis if they can do anything about it.
  
   Robert
  
 

   
  
 

Re: Travis-CI builds queuing up

[Robert Metzger]

I just found out that the execution time limit for the container-based
infra (the one we're using) is 120 minutes ;)
So we have some room left to write more test ;) (But please don't overdo it
)

On Tue, Mar 31, 2015 at 11:32 AM, Maximilian Michels m...@apache.org wrote:

 Very nice. Thanks Robert!

 On Mon, Mar 30, 2015 at 9:13 PM, Robert Metzger rmetz...@apache.org
 wrote:

  It seems that the issue is fixed. I've just pushed two times to a pull
  request and it immediately started building both.
  I think the apache user has much more parallel builds available now (we
  don't have any builds queuing up anymore).
 
  On Thu, Mar 26, 2015 at 4:06 PM, Henry Saputra henry.sapu...@gmail.com
  wrote:
 
   Awesome news!
  
   On Thursday, March 26, 2015, Robert Metzger rmetz...@apache.org
 wrote:
  
Travis replied me with very good news: Somebody from INFRA was asking
  the
same question around the same time as I did and Travis is working on
   adding
more build capacity for the apache github organization.
I hope we'll soon have quicker builds again.
   
On Tue, Mar 24, 2015 at 4:42 PM, Henry Saputra 
  henry.sapu...@gmail.com
javascript:;
wrote:
   
 That's good idea.

 Should be good to have mix of stable with Apache Jenkins for master
 and PRs, and Travis for individual forks.

 - Henry

 On Tue, Mar 24, 2015 at 8:03 AM, Maximilian Michels 
 m...@apache.org
javascript:;
 wrote:
  Hey!
 
  I would also like to continue using Travis but the current
  situation
   is
 not
  acceptable because we practically can't use Travis anymore for
 pull
  requests or the current master. If it cannot be resolved then I
  think
we
  should move on.
 
  The builds service team [1] at Apache offers Jenkins [2] for
   continuous
  integration. I think it should be fairly simple to set up. We
 could
still
  use Travis in our forked repositories but have a reliable CI
  solution
for
  the master and pull requests.
 
  Max
 
  [1] https://builds.apache.org/
  [2] http://jenkins-ci.org
 
  On Tue, Mar 24, 2015 at 3:46 PM, Márton Balassi 
 balassi.mar...@gmail.com javascript:;
  wrote:
 
  I also like the travis infrastucture. Thanks for bringing this
 up
   and
  reaching out to the travis guys.
 
  On Tue, Mar 24, 2015 at 3:38 PM, Robert Metzger 
   rmetz...@apache.org
javascript:;
  wrote:
 
   Hi guys,
  
   the build queue on travis is getting very very long. It seems
  that
it
  takes
   4 days now until commits to master are build. The nightly
 builds
from
 the
   website and the maven snapshots are also delayed by that.
   Right now,  there are 33 pull request builds scheduled (
   https://travis-ci.org/apache/flink/pull_requests), and 8
 builds
   on
  master:
   https://travis-ci.org/apache/flink/builds.
  
   The problem is that travis accounts are per github user. In
 our
case,
 the
   user is apache, so all ASF projects that have travis enabled
share 5
   concurrent builders.
  
   I would actually like to continue using Travis.
  
   The easiest option is probably asking travis if they can give
  the
  apache
   user more build capacity.
  
   If thats not possible, we have to look into other options.
  
  
   I'm going to ask Travis if they can do anything about it.
  
   Robert
  
 

   
  
 

Re: Travis-CI builds queuing up

[Maximilian Michels]

Very nice. Thanks Robert!

On Mon, Mar 30, 2015 at 9:13 PM, Robert Metzger rmetz...@apache.org wrote:

 It seems that the issue is fixed. I've just pushed two times to a pull
 request and it immediately started building both.
 I think the apache user has much more parallel builds available now (we
 don't have any builds queuing up anymore).

 On Thu, Mar 26, 2015 at 4:06 PM, Henry Saputra henry.sapu...@gmail.com
 wrote:

  Awesome news!
 
  On Thursday, March 26, 2015, Robert Metzger rmetz...@apache.org wrote:
 
   Travis replied me with very good news: Somebody from INFRA was asking
 the
   same question around the same time as I did and Travis is working on
  adding
   more build capacity for the apache github organization.
   I hope we'll soon have quicker builds again.
  
   On Tue, Mar 24, 2015 at 4:42 PM, Henry Saputra 
 henry.sapu...@gmail.com
   javascript:;
   wrote:
  
That's good idea.
   
Should be good to have mix of stable with Apache Jenkins for master
and PRs, and Travis for individual forks.
   
- Henry
   
On Tue, Mar 24, 2015 at 8:03 AM, Maximilian Michels m...@apache.org
   javascript:;
wrote:
 Hey!

 I would also like to continue using Travis but the current
 situation
  is
not
 acceptable because we practically can't use Travis anymore for pull
 requests or the current master. If it cannot be resolved then I
 think
   we
 should move on.

 The builds service team [1] at Apache offers Jenkins [2] for
  continuous
 integration. I think it should be fairly simple to set up. We could
   still
 use Travis in our forked repositories but have a reliable CI
 solution
   for
 the master and pull requests.

 Max

 [1] https://builds.apache.org/
 [2] http://jenkins-ci.org

 On Tue, Mar 24, 2015 at 3:46 PM, Márton Balassi 
balassi.mar...@gmail.com javascript:;
 wrote:

 I also like the travis infrastucture. Thanks for bringing this up
  and
 reaching out to the travis guys.

 On Tue, Mar 24, 2015 at 3:38 PM, Robert Metzger 
  rmetz...@apache.org
   javascript:;
 wrote:

  Hi guys,
 
  the build queue on travis is getting very very long. It seems
 that
   it
 takes
  4 days now until commits to master are build. The nightly builds
   from
the
  website and the maven snapshots are also delayed by that.
  Right now,  there are 33 pull request builds scheduled (
  https://travis-ci.org/apache/flink/pull_requests), and 8 builds
  on
 master:
  https://travis-ci.org/apache/flink/builds.
 
  The problem is that travis accounts are per github user. In our
   case,
the
  user is apache, so all ASF projects that have travis enabled
   share 5
  concurrent builders.
 
  I would actually like to continue using Travis.
 
  The easiest option is probably asking travis if they can give
 the
 apache
  user more build capacity.
 
  If thats not possible, we have to look into other options.
 
 
  I'm going to ask Travis if they can do anything about it.
 
  Robert
 

   
  
 

Re: Travis-CI builds queuing up

[Robert Metzger]

It seems that the issue is fixed. I've just pushed two times to a pull
request and it immediately started building both.
I think the apache user has much more parallel builds available now (we
don't have any builds queuing up anymore).

On Thu, Mar 26, 2015 at 4:06 PM, Henry Saputra henry.sapu...@gmail.com
wrote:

 Awesome news!

 On Thursday, March 26, 2015, Robert Metzger rmetz...@apache.org wrote:

  Travis replied me with very good news: Somebody from INFRA was asking the
  same question around the same time as I did and Travis is working on
 adding
  more build capacity for the apache github organization.
  I hope we'll soon have quicker builds again.
 
  On Tue, Mar 24, 2015 at 4:42 PM, Henry Saputra henry.sapu...@gmail.com
  javascript:;
  wrote:
 
   That's good idea.
  
   Should be good to have mix of stable with Apache Jenkins for master
   and PRs, and Travis for individual forks.
  
   - Henry
  
   On Tue, Mar 24, 2015 at 8:03 AM, Maximilian Michels m...@apache.org
  javascript:;
   wrote:
Hey!
   
I would also like to continue using Travis but the current situation
 is
   not
acceptable because we practically can't use Travis anymore for pull
requests or the current master. If it cannot be resolved then I think
  we
should move on.
   
The builds service team [1] at Apache offers Jenkins [2] for
 continuous
integration. I think it should be fairly simple to set up. We could
  still
use Travis in our forked repositories but have a reliable CI solution
  for
the master and pull requests.
   
Max
   
[1] https://builds.apache.org/
[2] http://jenkins-ci.org
   
On Tue, Mar 24, 2015 at 3:46 PM, Márton Balassi 
   balassi.mar...@gmail.com javascript:;
wrote:
   
I also like the travis infrastucture. Thanks for bringing this up
 and
reaching out to the travis guys.
   
On Tue, Mar 24, 2015 at 3:38 PM, Robert Metzger 
 rmetz...@apache.org
  javascript:;
wrote:
   
 Hi guys,

 the build queue on travis is getting very very long. It seems that
  it
takes
 4 days now until commits to master are build. The nightly builds
  from
   the
 website and the maven snapshots are also delayed by that.
 Right now,  there are 33 pull request builds scheduled (
 https://travis-ci.org/apache/flink/pull_requests), and 8 builds
 on
master:
 https://travis-ci.org/apache/flink/builds.

 The problem is that travis accounts are per github user. In our
  case,
   the
 user is apache, so all ASF projects that have travis enabled
  share 5
 concurrent builders.

 I would actually like to continue using Travis.

 The easiest option is probably asking travis if they can give the
apache
 user more build capacity.

 If thats not possible, we have to look into other options.


 I'm going to ask Travis if they can do anything about it.

 Robert

   
  
 

Re: Travis-CI builds queuing up

[Fabian Hueske]

Great!
Thanks Robert for sharing the good news :-)

2015-03-26 9:08 GMT+01:00 Robert Metzger rmetz...@apache.org:

 Travis replied me with very good news: Somebody from INFRA was asking the
 same question around the same time as I did and Travis is working on adding
 more build capacity for the apache github organization.
 I hope we'll soon have quicker builds again.

 On Tue, Mar 24, 2015 at 4:42 PM, Henry Saputra henry.sapu...@gmail.com
 wrote:

  That's good idea.
 
  Should be good to have mix of stable with Apache Jenkins for master
  and PRs, and Travis for individual forks.
 
  - Henry
 
  On Tue, Mar 24, 2015 at 8:03 AM, Maximilian Michels m...@apache.org
  wrote:
   Hey!
  
   I would also like to continue using Travis but the current situation is
  not
   acceptable because we practically can't use Travis anymore for pull
   requests or the current master. If it cannot be resolved then I think
 we
   should move on.
  
   The builds service team [1] at Apache offers Jenkins [2] for continuous
   integration. I think it should be fairly simple to set up. We could
 still
   use Travis in our forked repositories but have a reliable CI solution
 for
   the master and pull requests.
  
   Max
  
   [1] https://builds.apache.org/
   [2] http://jenkins-ci.org
  
   On Tue, Mar 24, 2015 at 3:46 PM, Márton Balassi 
  balassi.mar...@gmail.com
   wrote:
  
   I also like the travis infrastucture. Thanks for bringing this up and
   reaching out to the travis guys.
  
   On Tue, Mar 24, 2015 at 3:38 PM, Robert Metzger rmetz...@apache.org
   wrote:
  
Hi guys,
   
the build queue on travis is getting very very long. It seems that
 it
   takes
4 days now until commits to master are build. The nightly builds
 from
  the
website and the maven snapshots are also delayed by that.
Right now,  there are 33 pull request builds scheduled (
https://travis-ci.org/apache/flink/pull_requests), and 8 builds on
   master:
https://travis-ci.org/apache/flink/builds.
   
The problem is that travis accounts are per github user. In our
 case,
  the
user is apache, so all ASF projects that have travis enabled
 share 5
concurrent builders.
   
I would actually like to continue using Travis.
   
The easiest option is probably asking travis if they can give the
   apache
user more build capacity.
   
If thats not possible, we have to look into other options.
   
   
I'm going to ask Travis if they can do anything about it.
   
Robert
   
  
 

Re: Travis-CI builds queuing up

[Maximilian Michels]

That's nice to hear. They didn't specify any time frame?

On Thu, Mar 26, 2015 at 9:25 AM, Fabian Hueske fhue...@gmail.com wrote:

 Great!
 Thanks Robert for sharing the good news :-)

 2015-03-26 9:08 GMT+01:00 Robert Metzger rmetz...@apache.org:

  Travis replied me with very good news: Somebody from INFRA was asking the
  same question around the same time as I did and Travis is working on
 adding
  more build capacity for the apache github organization.
  I hope we'll soon have quicker builds again.
 
  On Tue, Mar 24, 2015 at 4:42 PM, Henry Saputra henry.sapu...@gmail.com
  wrote:
 
   That's good idea.
  
   Should be good to have mix of stable with Apache Jenkins for master
   and PRs, and Travis for individual forks.
  
   - Henry
  
   On Tue, Mar 24, 2015 at 8:03 AM, Maximilian Michels m...@apache.org
   wrote:
Hey!
   
I would also like to continue using Travis but the current situation
 is
   not
acceptable because we practically can't use Travis anymore for pull
requests or the current master. If it cannot be resolved then I think
  we
should move on.
   
The builds service team [1] at Apache offers Jenkins [2] for
 continuous
integration. I think it should be fairly simple to set up. We could
  still
use Travis in our forked repositories but have a reliable CI solution
  for
the master and pull requests.
   
Max
   
[1] https://builds.apache.org/
[2] http://jenkins-ci.org
   
On Tue, Mar 24, 2015 at 3:46 PM, Márton Balassi 
   balassi.mar...@gmail.com
wrote:
   
I also like the travis infrastucture. Thanks for bringing this up
 and
reaching out to the travis guys.
   
On Tue, Mar 24, 2015 at 3:38 PM, Robert Metzger 
 rmetz...@apache.org
wrote:
   
 Hi guys,

 the build queue on travis is getting very very long. It seems that
  it
takes
 4 days now until commits to master are build. The nightly builds
  from
   the
 website and the maven snapshots are also delayed by that.
 Right now,  there are 33 pull request builds scheduled (
 https://travis-ci.org/apache/flink/pull_requests), and 8 builds
 on
master:
 https://travis-ci.org/apache/flink/builds.

 The problem is that travis accounts are per github user. In our
  case,
   the
 user is apache, so all ASF projects that have travis enabled
  share 5
 concurrent builders.

 I would actually like to continue using Travis.

 The easiest option is probably asking travis if they can give the
apache
 user more build capacity.

 If thats not possible, we have to look into other options.


 I'm going to ask Travis if they can do anything about it.

 Robert

   
  
 

Re: Travis-CI builds queuing up

[Robert Metzger]

Travis replied me with very good news: Somebody from INFRA was asking the
same question around the same time as I did and Travis is working on adding
more build capacity for the apache github organization.
I hope we'll soon have quicker builds again.

On Tue, Mar 24, 2015 at 4:42 PM, Henry Saputra henry.sapu...@gmail.com
wrote:

 That's good idea.

 Should be good to have mix of stable with Apache Jenkins for master
 and PRs, and Travis for individual forks.

 - Henry

 On Tue, Mar 24, 2015 at 8:03 AM, Maximilian Michels m...@apache.org
 wrote:
  Hey!
 
  I would also like to continue using Travis but the current situation is
 not
  acceptable because we practically can't use Travis anymore for pull
  requests or the current master. If it cannot be resolved then I think we
  should move on.
 
  The builds service team [1] at Apache offers Jenkins [2] for continuous
  integration. I think it should be fairly simple to set up. We could still
  use Travis in our forked repositories but have a reliable CI solution for
  the master and pull requests.
 
  Max
 
  [1] https://builds.apache.org/
  [2] http://jenkins-ci.org
 
  On Tue, Mar 24, 2015 at 3:46 PM, Márton Balassi 
 balassi.mar...@gmail.com
  wrote:
 
  I also like the travis infrastucture. Thanks for bringing this up and
  reaching out to the travis guys.
 
  On Tue, Mar 24, 2015 at 3:38 PM, Robert Metzger rmetz...@apache.org
  wrote:
 
   Hi guys,
  
   the build queue on travis is getting very very long. It seems that it
  takes
   4 days now until commits to master are build. The nightly builds from
 the
   website and the maven snapshots are also delayed by that.
   Right now,  there are 33 pull request builds scheduled (
   https://travis-ci.org/apache/flink/pull_requests), and 8 builds on
  master:
   https://travis-ci.org/apache/flink/builds.
  
   The problem is that travis accounts are per github user. In our case,
 the
   user is apache, so all ASF projects that have travis enabled share 5
   concurrent builders.
  
   I would actually like to continue using Travis.
  
   The easiest option is probably asking travis if they can give the
  apache
   user more build capacity.
  
   If thats not possible, we have to look into other options.
  
  
   I'm going to ask Travis if they can do anything about it.
  
   Robert
  
 

Re: Travis-CI builds queuing up

[Henry Saputra]

If we could not get more capacity we could set up ASF Jenkins instead.
It is already used to power CI for many ASF projects like Hadoop so should
not be too shabby.

I have created ticket for Flink to setup ASF Jenkins but have not found
time to work on it.

- Henry

On Tuesday, March 24, 2015, Robert Metzger rmetz...@apache.org wrote:

 Hi guys,

 the build queue on travis is getting very very long. It seems that it takes
 4 days now until commits to master are build. The nightly builds from the
 website and the maven snapshots are also delayed by that.
 Right now,  there are 33 pull request builds scheduled (
 https://travis-ci.org/apache/flink/pull_requests), and 8 builds on master:
 https://travis-ci.org/apache/flink/builds.

 The problem is that travis accounts are per github user. In our case, the
 user is apache, so all ASF projects that have travis enabled share 5
 concurrent builders.

 I would actually like to continue using Travis.

 The easiest option is probably asking travis if they can give the apache
 user more build capacity.

 If thats not possible, we have to look into other options.


 I'm going to ask Travis if they can do anything about it.

 Robert

Re: Travis-CI builds queuing up

[Ufuk Celebi]

Let's see what Travis replies to Robert, but in general I agree with Max.

Travis helped a lot to discover certain race conditions in the last weeks... I 
would like to not ditch it completely as Max suggested.

On 24 Mar 2015, at 16:03, Maximilian Michels m...@apache.org wrote:

 I would also like to continue using Travis but the current situation is not
 acceptable because we practically can't use Travis anymore for pull
 requests or the current master. If it cannot be resolved then I think we
 should move on.
 The builds service team [1] at Apache offers Jenkins [2] for continuous
 integration. I think it should be fairly simple to set up. We could still
 use Travis in our forked repositories but have a reliable CI solution for
 the master and pull requests.