flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maximilian Michels <...@apache.org>
Subject Re: Travis-CI builds queuing up
Date Tue, 24 Mar 2015 15:03:01 GMT
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.marton@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 <rmetzger@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
> >
>

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