From what I gathered, there's no special sauce that the Zeppelin
project uses which actually integrates a users Travis account into the PR.
They just disabled Travis for PRs. And that's kind of it.
Naturally we can do this (duh) and safe the ASF a fair amount of
resources, but there are downsides:
The discoverability of the Travis check takes a nose-dive. Either we
require every contributor to always, an every commit, also post a Travis
build, or we have the reviewer sift through the contributors account to
find it.
This is rather cumbersome. Additionally, it's also not equivalent to
having a PR build.
A normal branch build takes a branch as is and tests it. A PR build
merges the branch into master, and then runs it. (Fun fact: This is why
a PR without merge conflicts is not being run on Travis.)
And ultimately, everyone can already make use of this approach anyway.
On 25/06/2019 08:02, Jark Wu wrote:
Hi Jeff,
Thanks for sharing the Zeppelin approach. I think it's a good idea to
leverage user's travis account.
In this way, we can have almost unlimited concurrent build jobs and
developers can restart build by themselves (currently only committers
can restart PR's build).
But I'm still not very clear how to integrate user's travis build into
the Flink pull request's build automatically. Can you explain more in
detail?
Another question: does travis only build branches for user account?
My concern is that builds for PRs will rebase user's commits against
current master branch.
This will help us to find problems before merge. Builds for branches
will lose the impact of new commits in master.
How does Zeppelin solve this problem?
Thanks again for sharing the idea.
Regards,
Jark
On Tue, 25 Jun 2019 at 11:01, Jeff Zhang <zjf...@gmail.com
<mailto:zjf...@gmail.com>> wrote:
Hi Folks,
Zeppelin meet this kind of issue before, we solve it by delegating
each
one's PR build to his travis account (Everyone can have 5 free
slot for
travis build).
Apache account travis build is only triggered when PR is merged.
Kurt Young <ykt...@gmail.com <mailto:ykt...@gmail.com>>
于2019年6月25日周二 上午10:16写道：
> (Forgot to cc George)
>
> Best,
> Kurt
>
>
> On Tue, Jun 25, 2019 at 10:16 AM Kurt Young <ykt...@gmail.com
<mailto:ykt...@gmail.com>> wrote:
>
> > Hi Bowen,
> >
> > Thanks for bringing this up. We actually have discussed about
this, and I
> > think Till and George have
> > already spend sometime investigating it. I have cced both of
them, and
> > maybe they can share
> > their findings.
> >
> > Best,
> > Kurt
> >
> >
> > On Tue, Jun 25, 2019 at 10:08 AM Jark Wu <imj...@gmail.com
<mailto:imj...@gmail.com>> wrote:
> >
> >> Hi Bowen,
> >>
> >> Thanks for bringing this. We also suffered from the long
build time.
> >> I agree that we should focus on solving build capacity
problem in the
> >> thread.
> >>
> >> My observation is there is only one build is running, all the
others
> >> (other
> >> PRs, master) are pending.
> >> The pricing plan[1] of travis shows it can support concurrent
build
> jobs.
> >> But I don't know which plan we are using, might be the free
plan for
> open
> >> source.
> >>
> >> I cc-ed Chesnay who may have some experience on Travis.
> >>
> >> Regards,
> >> Jark
> >>
> >> [1]: https://travis-ci.com/plans
> >>
> >> On Tue, 25 Jun 2019 at 08:11, Bowen Li <bowenl...@gmail.com
<mailto:bowenl...@gmail.com>> wrote:
> >>
> >> > Hi Steven,
> >> >
> >> > I think you may not read what I wrote. The discussion is about
> "unstable
> >> > build **capacity**", in another word "unstable / lack of build
> >> resources",
> >> > not "unstable build".
> >> >
> >> > On Mon, Jun 24, 2019 at 4:40 PM Steven Wu
<stevenz...@gmail.com <mailto:stevenz...@gmail.com>>
> wrote:
> >> >
> >> > > long and sometimes unstable build is definitely a pain point.
> >> > >
> >> > > I suspect the build failure here in flink-connector-kafka
is not
> >> related
> >> > to
> >> > > my change. but there is no easy re-run the build on
travis UI.
> Google
> >> > > search showed a trick of close-and-open the PR will
trigger rebuild.
> >> but
> >> > > that could add noises to the PR activities.
> >> > > https://travis-ci.org/apache/flink/jobs/545555519
> >> > >
> >> > > travis-ci for my personal repo often failed with
exceeding time
> limit
> >> > after
> >> > > 4+ hours.
> >> > > The job exceeded the maximum time limit for jobs, and has
been
> >> > terminated.
> >> > >
> >> > > On Mon, Jun 24, 2019 at 4:15 PM Bowen Li
<bowenl...@gmail.com <mailto:bowenl...@gmail.com>>
> wrote:
> >> > >
> >> > > > https://travis-ci.org/apache/flink/builds/549681530
This build
> >> > request
> >> > > > has
> >> > > > been sitting at **HEAD of the queue** since I first saw
it at PST
> >> > 10:30am
> >> > > > (not sure how long it's been there before 10:30am).
It's PST
> 4:12pm
> >> now
> >> > > and
> >> > > > it hasn't started yet.
> >> > > >
> >> > > > On Mon, Jun 24, 2019 at 2:48 PM Bowen Li
<bowenl...@gmail.com <mailto:bowenl...@gmail.com>>
> >> wrote:
> >> > > >
> >> > > > > Hi devs,
> >> > > > >
> >> > > > > I've been experiencing the pain resulting from lack
of stable
> >> build
> >> > > > > capacity on Travis for Flink PRs [1]. Specifically, I
noticed
> >> often
> >> > > that
> >> > > > no
> >> > > > > build in the queue is making any progress for hours, and
> suddenly
> >> 5
> >> > or
> >> > > 6
> >> > > > > builds kick off all together after the long pause.
I'm at PST
> >> > (UTC-08)
> >> > > > time
> >> > > > > zone, and I've seen pause can be as long as 6 hours
from PST 9am
> >> to
> >> > 3pm
> >> > > > > (let alone the time needed to drain the queue
afterwards).
> >> > > > >
> >> > > > > I think this has greatly impacted our productivity. I've
> >> experienced
> >> > > that
> >> > > > > PRs submitted in the early morning of PST time zone
won't finish
> >> > their
> >> > > > > build until late night of the same day.
> >> > > > >
> >> > > > > So my questions are:
> >> > > > >
> >> > > > > - Has anyone else experienced the same problem or
have similar
> >> > > > observation
> >> > > > > on TravisCI? (I suspect it has things to do with time
zone)
> >> > > > >
> >> > > > > - What pricing plan of TravisCI is Flink currently
using? Is it
> >> the
> >> > > free
> >> > > > > plan for open source projects? What are the
guaranteed build
> >> capacity
> >> > > of
> >> > > > > the current plan?
> >> > > > >
> >> > > > > - If the current pricing plan (either free or paid) can't
> provide
> >> > > stable
> >> > > > > build capacity, can we upgrade to a higher priced
plan with
> larger
> >> > and
> >> > > > more
> >> > > > > stable build capacity?
> >> > > > >
> >> > > > > BTW, another factor that contribute to the
productivity problem
> is
> >> > that
> >> > > > > our build is slow - we run full build for every PR and a
> >> successful
> >> > > full
> >> > > > > build takes ~5h. We definitely have more options to
solve it,
> for
> >> > > > instance,
> >> > > > > modularize the build graphs and reuse artifacts from the
> previous
> >> > > build.
> >> > > > > But I think that can be a big effort which is much
harder to
> >> > accomplish
> >> > > > in
> >> > > > > a short period of time and may deserve its own separate
> >> discussion.
> >> > > > >
> >> > > > > [1] https://travis-ci.org/apache/flink/pull_requests
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>
--
Best Regards
Jeff Zhang
