Wow. That's great! Thanks Chesnay. On Fri, 2 Aug 2019 at 17:50, Chesnay Schepler <ches...@apache.org> wrote:
> I'm currently modifying the cibot to do this automatically; should be > finished until Monday. > > On 02/08/2019 07:41, Jark Wu wrote: > > Hi Chesnay, > > > > Can we assign Flink Committers the permission of flink-ci/flink repo? > > Several times, when I pushed some new commits, the old build jobs are > still > > in pending and not canceled. > > Before we fix that, we can manually cancel some old jobs to save build > > resource. > > > > Best, > > Jark > > > > > > On Wed, 10 Jul 2019 at 16:17, Chesnay Schepler <ches...@apache.org> > wrote: > > > >> Your best bet would be to check the first commit in the PR and check the > >> parent commit. > >> > >> To re-run things, you will have to rebase the PR on the latest master. > >> > >> On 10/07/2019 03:32, Kurt Young wrote: > >>> Thanks for all your efforts Chesnay, it indeed improves a lot for our > >>> develop experience. BTW, do you know how to find the master branch > >>> information which the CI runs with? > >>> > >>> For example, like this one: > >>> https://travis-ci.com/flink-ci/flink/jobs/214542568 > >>> It shows pass with the commits, which rebased on the master when the CI > >>> is triggered. But it's both possible that the master branch CI runs on > is > >>> the > >>> same or different with current master. If it's the same, I can simply > >> rely > >>> on the > >>> passed information to push commits, but if it's not, I think i should > >> find > >>> another > >>> way to re-trigger tests based on the newest master. > >>> > >>> Do you know where can I get such information? > >>> > >>> Best, > >>> Kurt > >>> > >>> > >>> On Tue, Jul 9, 2019 at 3:27 AM Chesnay Schepler <ches...@apache.org> > >> wrote: > >>>> The kinks have been worked out; the bot is running again and pr builds > >>>> are yet again no longer running on ASF resources. > >>>> > >>>> PRs are mirrored to: https://github.com/flink-ci/flink > >>>> Bot source: https://github.com/flink-ci/ci-bot > >>>> > >>>> On 08/07/2019 17:14, Chesnay Schepler wrote: > >>>>> I have temporarily re-enabled running PR builds on the ASF account; > >>>>> migrating to the Travis subscription caused some issues in the bot > >>>>> that I have to fix first. > >>>>> > >>>>> On 07/07/2019 23:01, Chesnay Schepler wrote: > >>>>>> The vote has passed unanimously in favor of migrating to a separate > >>>>>> Travis account. > >>>>>> > >>>>>> I will now set things up such that no PullRequest is no longer run > on > >>>>>> the ASF servers. > >>>>>> This is a major setup in reducing our usage of ASF resources. > >>>>>> For the time being we'll use free Travis plan for flink-ci (i.e. 5 > >>>>>> workers, which is the same the ASF gives us). Over the course of the > >>>>>> next week we'll setup the Ververica subscription to increase this > >> limit. > >>>>>> From now now, a bot will mirror all new and updated PullRequests > to a > >>>>>> mirror repository (https://github.com/flink-ci/flink-ci) and write > an > >>>>>> update into the PR once the build is complete. > >>>>>> I have ran the bots for the past 3 days in parallel to our existing > >>>>>> Travis and it was working without major issues. > >>>>>> > >>>>>> The biggest change that contributors will see is that there's no > >>>>>> longer a icon next to each commit. We may revisit this in the > future. > >>>>>> > >>>>>> I'll setup a repo with the source of the bot later. > >>>>>> > >>>>>> On 04/07/2019 10:46, Chesnay Schepler wrote: > >>>>>>> I've raised a JIRA > >>>>>>> <https://issues.apache.org/jira/browse/INFRA-18703>with INFRA to > >>>>>>> inquire whether it would be possible to switch to a different > Travis > >>>>>>> account, and if so what steps would need to be taken. > >>>>>>> We need a proper confirmation from INFRA since we are not in full > >>>>>>> control of the flink repository (for example, we cannot access the > >>>>>>> settings page). > >>>>>>> > >>>>>>> If this is indeed possible, Ververica is willing sponsor a Travis > >>>>>>> account for the Flink project. > >>>>>>> This would provide us with more than enough resources than we need. > >>>>>>> > >>>>>>> Since this makes the project more reliant on resources provided by > >>>>>>> external companies I would like to vote on this. > >>>>>>> > >>>>>>> Please vote on this proposal, as follows: > >>>>>>> [ ] +1, Approve the migration to a Ververica-sponsored Travis > >>>>>>> account, provided that INFRA approves > >>>>>>> [ ] -1, Do not approach the migration to a Ververica-sponsored > >>>>>>> Travis account > >>>>>>> > >>>>>>> The vote will be open for at least 24h, and until we have > >>>>>>> confirmation from INFRA. The voting period may be shorter than the > >>>>>>> usual 3 days since our current is effectively not working. > >>>>>>> > >>>>>>> On 04/07/2019 06:51, Bowen Li wrote: > >>>>>>>> Re: > Are they using their own Travis CI pool, or did the switch > to > >>>>>>>> an entirely different CI service? > >>>>>>>> > >>>>>>>> I reached out to Wes and Krisztián from Apache Arrow PMC. They are > >>>>>>>> currently moving away from ASF's Travis to their own in-house > metal > >>>>>>>> machines at [1] with custom CI application at [2]. They've seen > >>>>>>>> significant improvement w.r.t both much higher performance and > >>>>>>>> basically no resource waiting time, "night-and-day" difference > >>>>>>>> quoting Wes. > >>>>>>>> > >>>>>>>> Re: > If we can just switch to our own Travis pool, just for our > >>>>>>>> project, then this might be something we can do fairly quickly? > >>>>>>>> > >>>>>>>> I believe so, according to [3] and [4] > >>>>>>>> > >>>>>>>> > >>>>>>>> [1] https://ci.ursalabs.org/ <https://ci.ursalabs.org/#/> > >>>>>>>> [2] https://github.com/ursa-labs/ursabot > >>>>>>>> [3] > >>>>>>>> > >> > https://docs.travis-ci.com/user/migrate/open-source-repository-migration > >>>>>>>> [4] > >>>>>>>> > >> https://docs.travis-ci.com/user/migrate/open-source-on-travis-ci-com > >>>>>>>> > >>>>>>>> > >>>>>>>> On Wed, Jul 3, 2019 at 12:01 AM Chesnay Schepler > >>>>>>>> <ches...@apache.org <mailto:ches...@apache.org>> wrote: > >>>>>>>> > >>>>>>>> Are they using their own Travis CI pool, or did the switch > to > >> an > >>>>>>>> entirely different CI service? > >>>>>>>> > >>>>>>>> If we can just switch to our own Travis pool, just for our > >>>>>>>> project, then > >>>>>>>> this might be something we can do fairly quickly? > >>>>>>>> > >>>>>>>> On 03/07/2019 05:55, Bowen Li wrote: > >>>>>>>> > I responded in the INFRA ticket [1] that I believe they > are > >>>>>>>> using a wrong > >>>>>>>> > metric against Flink and the total build time is a > completely > >>>>>>>> different > >>>>>>>> > thing than guaranteed build capacity. > >>>>>>>> > > >>>>>>>> > My response: > >>>>>>>> > > >>>>>>>> > "As mentioned above, since I started to pay attention to > >> Flink's > >>>>>>>> build > >>>>>>>> > queue a few tens of days ago, I'm in Seattle and I saw no > >> build > >>>>>>>> was kicking > >>>>>>>> > off in PST daytime in weekdays for Flink. Our teammates in > >> China > >>>>>>>> and Europe > >>>>>>>> > have also reported similar observations. So we need to > >> evaluate > >>>>>>>> how the > >>>>>>>> > large total build time came from - if 1) your number and > 2) > >> our > >>>>>>>> > observations from three locations that cover pretty much a > >> full > >>>>>>>> day, are > >>>>>>>> > all true, I **guess** one reason can be that - highly > likely > >> the > >>>>>>>> extra > >>>>>>>> > build time came from weekends when other Apache projects > may > >> be > >>>>>>>> idle and > >>>>>>>> > Flink just drains hard its congested queue. > >>>>>>>> > > >>>>>>>> > Please be aware of that we're not complaining about the > lack > >> of > >>>>>>>> resources > >>>>>>>> > in general, I'm complaining about the lack of **stable, > >>>>>>>> dedicated** > >>>>>>>> > resources. An example for the latter one is, currently > even > >> if > >>>>>>>> no build is > >>>>>>>> > in Flink's queue and I submit a request to be the queue > head > >>>>>>>> in PST > >>>>>>>> > morning, my build won't even start in 6-8+h. That is an > >> absurd > >>>>>>>> amount of > >>>>>>>> > waiting time. > >>>>>>>> > > >>>>>>>> > That's saying, if ASF INFRA decides to adopt a quota > system > >> and > >>>>>>>> grants > >>>>>>>> > Flink five DEDICATED servers that runs all the time only > for > >>>>>>>> Flink, that'll > >>>>>>>> > be PERFECT and can totally solve our problem now. > >>>>>>>> > > >>>>>>>> > Please be aware of that we're not complaining about the > lack > >> of > >>>>>>>> resources > >>>>>>>> > in general, I'm complaining about the lack of **stable, > >>>>>>>> dedicated** > >>>>>>>> > resources. An example for the latter one is, currently > even > >> if > >>>>>>>> no build is > >>>>>>>> > in Flink's queue and I submit a request to be the queue > head > >>>>>>>> in PST > >>>>>>>> > morning, my build won't even start in 6-8+h. That is an > >> absurd > >>>>>>>> amount of > >>>>>>>> > waiting time. > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > That's saying, if ASF INFRA decides to adopt a quota > system > >> and > >>>>>>>> grants > >>>>>>>> > Flink five DEDICATED servers that runs all the time only > for > >>>>>>>> Flink, that'll > >>>>>>>> > be PERFECT and can totally solve our problem now. > >>>>>>>> > > >>>>>>>> > I feel what's missing in the ASF INFRA's Travis resource > >> pool is > >>>>>>>> some level > >>>>>>>> > of build capacity SLAs and certainty" > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > Again, I believe there are differences in nature of these > two > >>>>>>>> problems, > >>>>>>>> > long build time v.s. lack of dedicated build resource. > That's > >>>>>>>> saying, > >>>>>>>> > shortening build time may relieve the situation, and may > not. > >>>>>>>> I'm sightly > >>>>>>>> > negative on disabling IT cases for PRs, due to the > downside > >> is > >>>>>>>> that we are > >>>>>>>> > at risk of any potential bugs in PR that UTs doesn't > catch, > >> and > >>>>>>>> may cost a > >>>>>>>> > lot more to fix and if it slows others down or even block > >>>>>>>> others, but am > >>>>>>>> > open to others opinions on it. > >>>>>>>> > > >>>>>>>> > AFAICT from INFRA ticket[1], donating to ASF INFRA won't > be > >>>>>>>> feasible to > >>>>>>>> > solve our problem since INFRA's pool is fully shared and > they > >>>>>>>> have no > >>>>>>>> > control and finer insights over resource allocation to a > >>>>>>>> specific Apache > >>>>>>>> > project. As mentioned in [1], Apache Arrow is moving away > >> from > >>>>>>>> ASF INFRA > >>>>>>>> > Travis pool (they are actually surprised Flink hasn't plan > >> to do > >>>>>>>> so). I > >>>>>>>> > know that Spark is on its own build infra. If we all agree > >> that > >>>>>>>> funding our > >>>>>>>> > own build infra, I'd be glad to help investigate any > >> potential > >>>>>>>> options > >>>>>>>> > after releasing 1.9 since I'm super busy with 1.9 now. > >>>>>>>> > > >>>>>>>> > [1] https://issues.apache.org/jira/browse/INFRA-18533 > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > On Tue, Jul 2, 2019 at 4:46 AM Chesnay Schepler > >>>>>>>> <ches...@apache.org <mailto:ches...@apache.org>> wrote: > >>>>>>>> > > >>>>>>>> >> As a short-term stopgap, since we can assume this issue > to > >>>>>>>> become much > >>>>>>>> >> worse in the following days/weeks, we could disable IT > >> cases in > >>>>>>>> PRs and > >>>>>>>> >> only run them on master. > >>>>>>>> >> > >>>>>>>> >> On 02/07/2019 12:03, Chesnay Schepler wrote: > >>>>>>>> >>> People really have to stop thinking that just because > >>>>>>>> something works > >>>>>>>> >>> for us it is also a good solution. > >>>>>>>> >>> Also, please remember that our builds run for 2h from > >> start to > >>>>>>>> finish, > >>>>>>>> >>> and not the 14 _minutes_ it takes for zeppelin. > >>>>>>>> >>> We are dealing with an entirely different scale here, > both > >> in > >>>>>>>> terms of > >>>>>>>> >>> build times and number of builds. > >>>>>>>> >>> > >>>>>>>> >>> In this very thread people have been complaining about > long > >>>>>>>> queue > >>>>>>>> >>> times for their builds. Surprise, other Apache projects > >>>>>>>> have been > >>>>>>>> >>> suffering the very same thing due to us not controlling > our > >>>>>>>> build > >>>>>>>> >>> times. While switching services (be it Jenkins, > CircleCI or > >>>>>>>> whatever) > >>>>>>>> >>> will possibly work for us (and these options are > actually > >>>>>>>> attractive, > >>>>>>>> >>> like CircleCI's proper support for build artifacts), it > >>>>>>>> will also > >>>>>>>> >>> result in us likely negatively affecting other projects > in > >>>>>>>> significant > >>>>>>>> >>> ways. > >>>>>>>> >>> > >>>>>>>> >>> Sure, the Jenkins setup has a good user experience for > us, > >> at > >>>>>>>> the cost > >>>>>>>> >>> of blocking Jenkins workers for a _lot_ of time. Right > now > >> we > >>>>>>>> have 25 > >>>>>>>> >>> PR's in our queue; that's possibly 50h we'd consume of > >> Jenkins > >>>>>>>> >>> resources, and the European contributors haven't even > >> really > >>>>>>>> started yet. > >>>>>>>> >>> > >>>>>>>> >>> FYI, the latest INFRA response from INFRA-18533: > >>>>>>>> >>> > >>>>>>>> >>> "Our rough metrics shows that Flink used over 5800 > hours of > >>>>>>>> build time > >>>>>>>> >>> last month. That is equal to EIGHT servers running 24/7 > for > >>>>>>>> the ENTIRE > >>>>>>>> >>> MONTH. EIGHT. nonstop. > >>>>>>>> >>> When we discovered this last night, we discussed it some > >> and > >>>>>>>> are going > >>>>>>>> >>> to tune down Flink to allow only five executors > maximum. We > >>>>>>>> cannot > >>>>>>>> >>> allow Flink to consume so much of a Foundation shared > >>>>>>>> resource." > >>>>>>>> >>> > >>>>>>>> >>> So yes, we either > >>>>>>>> >>> a) have to heavily reduce our CI usage or > >>>>>>>> >>> b) fund our own, either maintaining it ourselves or > >> donating > >>>>>>>> to Apache. > >>>>>>>> >>> > >>>>>>>> >>> On 02/07/2019 05:11, Bowen Li wrote: > >>>>>>>> >>>> By looking at the git history of the Jenkins script, > its > >> core > >>>>>>>> part > >>>>>>>> >>>> was finished in March 2017 (and only two minor update > in > >>>>>>>> 2017/2018), > >>>>>>>> >>>> so it's been running for over two years now and feels > like > >>>>>>>> Zepplin > >>>>>>>> >>>> community has been quite happy with it. @Jeff Zhang > >>>>>>>> >>>> <mailto:zjf...@gmail.com <mailto:zjf...@gmail.com>> > can > >> you > >>>>>>>> share your insights and user > >>>>>>>> >>>> experience with the Jenkins+Travis approach? > >>>>>>>> >>>> > >>>>>>>> >>>> Things like: > >>>>>>>> >>>> > >>>>>>>> >>>> - has the approach completely solved the resource > capacity > >>>>>>>> problem > >>>>>>>> >>>> for Zepplin community? is Zepplin community happy with > the > >>>>>>>> result? > >>>>>>>> >>>> - is the whole configuration chain stable (e.g. uptime) > >>>>>>>> enough? > >>>>>>>> >>>> - how often do you need to maintain the Jenkins infra? > how > >>>>>>>> many > >>>>>>>> >>>> people are usually involved in maintenance and > bug-fixes? > >>>>>>>> >>>> > >>>>>>>> >>>> The downside of this approach seems mostly to be on the > >>>>>>>> maintenance > >>>>>>>> >>>> to me - maintain the script and Jenkins infra. > >>>>>>>> >>>> > >>>>>>>> >>>> ** Having Our Own Travis-CI.com Account ** > >>>>>>>> >>>> > >>>>>>>> >>>> Another alternative I've been thinking of is to have > our > >> own > >>>>>>>> >>>> travis-ci.com <http://travis-ci.com> < > >> http://travis-ci.com> > >>>>>>>> account with paid dedicated > >>>>>>>> >>>> resources. Note travis-ci.org <http://travis-ci.org> > >>>>>>>> <http://travis-ci.org> is the free > >>>>>>>> >>>> version and travis-ci.com <http://travis-ci.com> > >>>>>>>> <http://travis-ci.com> is the commercial > >>>>>>>> >>>> version. We currently use a shared resource pool > managed > >> by > >>>>>>>> ASK INFRA > >>>>>>>> >>>> team on travis-ci.org <http://travis-ci.org> > >>>>>>>> <http://travis-ci.org>, but we have no control > >>>>>>>> >>>> over it - we can't see how it's configured, how much > >>>>>>>> resources are > >>>>>>>> >>>> available, how resources are allocated among Apache > >> projects, > >>>>>>>> etc. > >>>>>>>> >>>> The nice thing about having an account on > travis-ci.com > >>>>>>>> <http://travis-ci.com> > >>>>>>>> >>>> <http://travis-ci.com> are: > >>>>>>>> >>>> > >>>>>>>> >>>> - relatively low cost with much better resource > guarantee > >>>>>>>> than what > >>>>>>>> >>>> we currently have [1]: $249/month with 5 dedicated > >>>>>>>> concurrency, > >>>>>>>> >>>> $489/month with 10 concurrency > >>>>>>>> >>>> - low maintenance work compared to using Jenkins > >>>>>>>> >>>> - (potentially) no migration cost according to Travis's > >>>>>>>> doc [2] > >>>>>>>> >>>> (pending verification) > >>>>>>>> >>>> - full control over the build capacity/configuration > >>>>>>>> compared to > >>>>>>>> >>>> using ASF INFRA's pool > >>>>>>>> >>>> > >>>>>>>> >>>> I'd be surprised if we as such a vibrant community > cannot > >>>>>>>> find and > >>>>>>>> >>>> fund $249*12=$2988 a year in exchange for a much better > >>>>>>>> developer > >>>>>>>> >>>> experience and much higher productivity. > >>>>>>>> >>>> > >>>>>>>> >>>> [1] https://travis-ci.com/plans > >>>>>>>> >>>> [2] > >>>>>>>> >>>> > >>>>>>>> >> > >>>>>>>> > >> > https://docs.travis-ci.com/user/migrate/open-source-repository-migration > >>>>>>>> >>>> On Sat, Jun 29, 2019 at 8:39 AM Chesnay Schepler > >>>>>>>> <ches...@apache.org <mailto:ches...@apache.org> > >>>>>>>> >>>> <mailto:ches...@apache.org <mailto:ches...@apache.org > >>> > >>>>>>>> wrote: > >>>>>>>> >>>> > >>>>>>>> >>>> So yes, the Jenkins job keeps pulling the state > from > >>>>>>>> Travis until it > >>>>>>>> >>>> finishes. > >>>>>>>> >>>> > >>>>>>>> >>>> Note sure I'm comfortable with the idea of using > >> Jenkins > >>>>>>>> workers > >>>>>>>> >>>> just to > >>>>>>>> >>>> idle for a several hours. > >>>>>>>> >>>> > >>>>>>>> >>>> On 29/06/2019 14:56, Jeff Zhang wrote: > >>>>>>>> >>>> > Here's what zeppelin community did, we make a > >> python > >>>>>>>> script to > >>>>>>>> >>>> check the > >>>>>>>> >>>> > build status of pull request. > >>>>>>>> >>>> > Here's script: > >>>>>>>> >>>> > > >>>>>>>> https://github.com/apache/zeppelin/blob/master/travis_check.py > >>>>>>>> >>>> > > >>>>>>>> >>>> > And this is the script we used in Jenkins build > >> job. > >>>>>>>> >>>> > > >>>>>>>> >>>> > if [ -f "travis_check.py" ]; then > >>>>>>>> >>>> > git log -n 1 > >>>>>>>> >>>> > STATUS=$(curl -s $BUILD_URL | grep -e "GitHub > >> pull > >>>>>>>> >>>> request.*from.*" | sed > >>>>>>>> >>>> > 's/.*GitHub pull request <a > >>>>>>>> >>>> > > >> href=\"\(https[^"]*\).*from[^"]*.\(https[^"]*\).*/\1 > >>>>>>>> \2/g') > >>>>>>>> >>>> > AUTHOR=$(echo $STATUS | sed > >> 's/.*[/]\(.*\)$/\1/g') > >>>>>>>> >>>> > PR=$(echo $STATUS | awk '{print $1}' | sed > >>>>>>>> >>>> 's/.*[/]\(.*\)$/\1/g') > >>>>>>>> >>>> > #COMMIT=$(git log -n 1 | grep "^Merge:" | awk > >>>>>>>> '{print $3}') > >>>>>>>> >>>> > #if [ -z $COMMIT ]; then > >>>>>>>> >>>> > # COMMIT=$(curl -s > >>>>>>>> >>>> https://api.github.com/repos/apache/zeppelin/pulls/$PR > >>>>>>>> >>>> > | grep -e "\"label\":" -e "\"ref\":" -e > "\"sha\":" > >> | > >>>>>>>> tr '\n' ' ' > >>>>>>>> >>>> | sed > >>>>>>>> >>>> > 's/\(.*sha[^,]*,\)\(.*ref.*\)/\1 = \2/g' | tr = > >> '\n' | > >>>>>>>> grep -v > >>>>>>>> >>>> "apache:" | > >>>>>>>> >>>> > sed 's/.*sha.[^"]*["]\([^"]*\).*/\1/g') > >>>>>>>> >>>> > #fi > >>>>>>>> >>>> > > >>>>>>>> >>>> > # get commit hash from PR > >>>>>>>> >>>> > COMMIT=$(curl -s > >>>>>>>> >>>> https://api.github.com/repos/apache/zeppelin/pulls/$PR > | > >>>>>>>> >>>> > grep -e "\"label\":" -e "\"ref\":" -e > "\"sha\":" | > >> tr > >>>>>>>> '\n' ' ' > >>>>>>>> >>>> | sed > >>>>>>>> >>>> > 's/\(.*sha[^,]*,\)\(.*ref.*\)/\1 = \2/g' | tr = > >> '\n' | > >>>>>>>> grep -v > >>>>>>>> >>>> "apache:" | > >>>>>>>> >>>> > sed 's/.*sha.[^"]*["]\([^"]*\).*/\1/g') > >>>>>>>> >>>> > sleep 30 # sleep few moment to wait travis > >> starts > >>>>>>>> the build > >>>>>>>> >>>> > RET_CODE=0 > >>>>>>>> >>>> > python ./travis_check.py ${AUTHOR} ${COMMIT} > || > >>>>>>>> RET_CODE=$? > >>>>>>>> >>>> > if [ $RET_CODE -eq 2 ]; then # try with > >> repository > >>>>>>>> name when > >>>>>>>> >>>> travis-ci is > >>>>>>>> >>>> > not available in the account > >>>>>>>> >>>> > RET_CODE=0 > >>>>>>>> >>>> > AUTHOR=$(curl -s > >>>>>>>> >>>> https://api.github.com/repos/apache/zeppelin/pulls/$PR > >>>>>>>> >>>> > | grep '"full_name":' | grep -v > "apache/zeppelin" | > >>>>>>>> sed > >>>>>>>> >>>> > 's/.*[:][^"]*["]\([^/]*\).*/\1/g') > >>>>>>>> >>>> > python ./travis_check.py ${AUTHOR} ${COMMIT} > || > >>>>>>>> RET_CODE=$? > >>>>>>>> >>>> > fi > >>>>>>>> >>>> > > >>>>>>>> >>>> > if [ $RET_CODE -eq 2 ]; then # fail with > can't > >> find > >>>>>>>> build > >>>>>>>> >>>> information in > >>>>>>>> >>>> > the travis > >>>>>>>> >>>> > set +x > >>>>>>>> >>>> > echo > >>>>>>>> "-----------------------------------------------------" > >>>>>>>> >>>> > echo "Looks like travis-ci is not > configured > >> for > >>>>>>>> your fork." > >>>>>>>> >>>> > echo "Please setup by swich on 'zeppelin' > >>>>>>>> repository at > >>>>>>>> >>>> > https://travis-ci.org/profile and travis-ci." > >>>>>>>> >>>> > echo "And then make sure 'Build branch > >> updates' > >>>>>>>> option is > >>>>>>>> >>>> enabled in > >>>>>>>> >>>> > the settings > >>>>>>>> https://travis-ci.org/${AUTHOR}/zeppelin/settings > >>>>>>>> <https://travis-ci.org/$%7BAUTHOR%7D/zeppelin/settings> > >>>>>>>> >>>> <https://travis-ci.org/$%7BAUTHOR%7D/zeppelin/settings > >." > >>>>>>>> >>>> > echo "" > >>>>>>>> >>>> > echo "To trigger CI after setup, you will > need > >>>>>>>> ammend your > >>>>>>>> >>>> last commit > >>>>>>>> >>>> > with" > >>>>>>>> >>>> > echo "git commit --amend" > >>>>>>>> >>>> > echo "git push your-remote HEAD --force" > >>>>>>>> >>>> > echo "" > >>>>>>>> >>>> > echo "See > >>>>>>>> >>>> > > >>>>>>>> >>>> > >>>>>>>> >> > >>>>>>>> > >> > http://zeppelin.apache.org/contribution/contributions.html#continuous-integration > >>>>>>>> >>>> > ." > >>>>>>>> >>>> > fi > >>>>>>>> >>>> > > >>>>>>>> >>>> > exit $RET_CODE > >>>>>>>> >>>> > else > >>>>>>>> >>>> > set +x > >>>>>>>> >>>> > echo "travis_check.py does not exists" > >>>>>>>> >>>> > exit 1 > >>>>>>>> >>>> > fi > >>>>>>>> >>>> > > >>>>>>>> >>>> > Chesnay Schepler <ches...@apache.org > >>>>>>>> <mailto:ches...@apache.org> > >>>>>>>> >>>> <mailto:ches...@apache.org <mailto: > >> ches...@apache.org > >>>>>>>> 于2019年6月29日周六 下午3:17写道： > >>>>>>>> >>>> > > >>>>>>>> >>>> >> Does this imply that a Jenkins job is active as > >> long > >>>>>>>> as the > >>>>>>>> >>>> Travis build > >>>>>>>> >>>> >> runs? > >>>>>>>> >>>> >> > >>>>>>>> >>>> >> On 26/06/2019 21:28, Bowen Li wrote: > >>>>>>>> >>>> >>> Hi, > >>>>>>>> >>>> >>> > >>>>>>>> >>>> >>> @Dawid, I think the "long test running" as I > >>>>>>>> mentioned in the > >>>>>>>> >>>> first > >>>>>>>> >>>> >> email, > >>>>>>>> >>>> >>> also as you guys said, belongs to "a big > effort > >>>>>>>> which is much > >>>>>>>> >>>> harder to > >>>>>>>> >>>> >>> accomplish in a short period of time and may > >> deserve > >>>>>>>> its own > >>>>>>>> >>>> separate > >>>>>>>> >>>> >>> discussion". Thus I didn't include it in what > we > >> can > >>>>>>>> do in a > >>>>>>>> >>>> foreseeable > >>>>>>>> >>>> >>> short term. > >>>>>>>> >>>> >>> > >>>>>>>> >>>> >>> Besides, I don't think that's the ultimate > reason > >>>>>>>> for lack of > >>>>>>>> >>>> build > >>>>>>>> >>>> >>> resources. Even if the build is shortened to > >>>>>>>> something like > >>>>>>>> >>>> 2h, the > >>>>>>>> >>>> >>> problems of no build machine works about 6 or > >> more > >>>>>>>> hours in > >>>>>>>> >>>> PST daytime > >>>>>>>> >>>> >>> that I described will still happen, because no > >>>>>>>> machine from > >>>>>>>> >>>> ASF INFRA's > >>>>>>>> >>>> >>> pool is allocated to Flink. As I have paid > close > >>>>>>>> attention to > >>>>>>>> >>>> the build > >>>>>>>> >>>> >>> queue in the past few weekdays, it's a pretty > >> clear > >>>>>>>> pattern now. > >>>>>>>> >>>> >>> > >>>>>>>> >>>> >>> **The ultimate root cause** for that is - we > >> don't > >>>>>>>> have any > >>>>>>>> >>>> **dedicated** > >>>>>>>> >>>> >>> build resources that we can stably rely on. > I'm > >>>>>>>> actually ok to > >>>>>>>> >>>> wait for a > >>>>>>>> >>>> >>> long time if there are build requests > running, it > >>>>>>>> means at > >>>>>>>> >>>> least we are > >>>>>>>> >>>> >>> making progress. But I'm not ok with no build > >>>>>>>> resource. A > >>>>>>>> >>>> better place I > >>>>>>>> >>>> >>> think we should aim at in short term is to > always > >>>>>>>> have at > >>>>>>>> >>>> least a central > >>>>>>>> >>>> >>> pool (can be 3 or 5) of machines dedicated to > >> build > >>>>>>>> Flink at > >>>>>>>> >>>> any time, or > >>>>>>>> >>>> >>> maybe use users resources. > >>>>>>>> >>>> >>> > >>>>>>>> >>>> >>> @Chesnay @Robert I synced with Jeff offline > that > >>>>>>>> Zeppelin > >>>>>>>> >>>> community is > >>>>>>>> >>>> >>> using a Jenkins job to automatically build on > >> users' > >>>>>>>> travis > >>>>>>>> >>>> account and > >>>>>>>> >>>> >>> link the result back to github PR. I guess the > >>>>>>>> Jenkins job > >>>>>>>> >>>> would fetch > >>>>>>>> >>>> >>> latest upstream master and build the PR > against > >> it. > >>>>>>>> Jeff has > >>>>>>>> >>>> filed > >>>>>>>> >>>> >> tickets > >>>>>>>> >>>> >>> to learn and get access to the Jenkins infra. > >> It'll > >>>>>>>> better to > >>>>>>>> >>>> fully > >>>>>>>> >>>> >>> understand it first before judging this > approach. > >>>>>>>> >>>> >>> > >>>>>>>> >>>> >>> I also heard good things about CircleCI, and > ASF > >>>>>>>> INFRA seems > >>>>>>>> >>>> to have a > >>>>>>>> >>>> >> pool > >>>>>>>> >>>> >>> of build capacity there too. Can be an > >> alternative > >>>>>>>> to consider. > >>>>>>>> >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> >>>> >>> > >>>>>>>> >>>> >>> On Wed, Jun 26, 2019 at 12:44 AM Dawid > >> Wysakowicz < > >>>>>>>> >>>> >> dwysakow...@apache.org > >>>>>>>> <mailto:dwysakow...@apache.org> <mailto: > dwysakow...@apache.org > >>>>>>>> <mailto:dwysakow...@apache.org>>> > >>>>>>>> >>>> >>> wrote: > >>>>>>>> >>>> >>> > >>>>>>>> >>>> >>>> Sorry to jump in late, but I think Bowen > missed > >> the > >>>>>>>> most > >>>>>>>> >>>> important point > >>>>>>>> >>>> >>>> from Chesnay's previous message in the > summary. > >> The > >>>>>>>> ultimate > >>>>>>>> >>>> reason for > >>>>>>>> >>>> >>>> all the problems is that the tests take close > >> to 2 > >>>>>>>> hours to > >>>>>>>> >>>> run already. > >>>>>>>> >>>> >>>> I fully support this claim: "Unless people > start > >>>>>>>> caring about > >>>>>>>> >>>> test times > >>>>>>>> >>>> >>>> before adding them, this issue cannot be > solved" > >>>>>>>> >>>> >>>> > >>>>>>>> >>>> >>>> This is also another reason why using user's > >> Travis > >>>>>>>> account > >>>>>>>> >>>> won't help. > >>>>>>>> >>>> >>>> Every few weeks we reach the user's time > limit > >> for > >>>>>>>> a single > >>>>>>>> >>>> profile. > >>>>>>>> >>>> >>>> This makes the user's builds simply fail, > until > >> we > >>>>>>>> either > >>>>>>>> >>>> properly > >>>>>>>> >>>> >>>> decrease the time the tests take (which I am > not > >>>>>>>> sure we ever > >>>>>>>> >>>> did) or > >>>>>>>> >>>> >>>> postpone the problem by splitting into more > >>>>>>>> profiles. (Note > >>>>>>>> >>>> that the ASF > >>>>>>>> >>>> >>>> Travis account has higher time limits) > >>>>>>>> >>>> >>>> > >>>>>>>> >>>> >>>> Best, > >>>>>>>> >>>> >>>> > >>>>>>>> >>>> >>>> Dawid > >>>>>>>> >>>> >>>> > >>>>>>>> >>>> >>>> On 26/06/2019 09:36, Robert Metzger wrote: > >>>>>>>> >>>> >>>>> Do we know if using "the best" available > >> hardware > >>>>>>>> would > >>>>>>>> >>>> improve the > >>>>>>>> >>>> >> build > >>>>>>>> >>>> >>>>> times? > >>>>>>>> >>>> >>>>> Imagine we would run the build on machines > with > >>>>>>>> plenty of > >>>>>>>> >>>> main memory > >>>>>>>> >>>> >> to > >>>>>>>> >>>> >>>>> mount everything to ramdisk + the latest CPU > >>>>>>>> architecture? > >>>>>>>> >>>> >>>>> > >>>>>>>> >>>> >>>>> Throwing hardware at the problem could help > >> reduce > >>>>>>>> the time > >>>>>>>> >>>> of an > >>>>>>>> >>>> >>>>> individual build, and using our own > >> infrastructure > >>>>>>>> would > >>>>>>>> >>>> remove our > >>>>>>>> >>>> >>>>> dependency on Apache's Travis account (with > the > >>>>>>>> obvious > >>>>>>>> >>>> downside of > >>>>>>>> >>>> >>>> having > >>>>>>>> >>>> >>>>> to maintain the infrastructure) > >>>>>>>> >>>> >>>>> We could use an open source travis > >> alternative, to > >>>>>>>> have a > >>>>>>>> >>>> similar > >>>>>>>> >>>> >>>>> experience and make the migration easy. > >>>>>>>> >>>> >>>>> > >>>>>>>> >>>> >>>>> > >>>>>>>> >>>> >>>>> On Wed, Jun 26, 2019 at 9:34 AM Chesnay > >> Schepler > >>>>>>>> >>>> <ches...@apache.org <mailto:ches...@apache.org> > >>>>>>>> <mailto:ches...@apache.org <mailto:ches...@apache.org>>> > >>>>>>>> >>>> >>>> wrote: > >>>>>>>> >>>> >>>>>> >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> > >>>>>>>> >>>> <mailto:zjf...@gmail.com <mailto:zjf...@gmail.com > >> > >>>>>>>> >>>> >>>>>>> <mailto:zjf...@gmail.com > >>>>>>>> <mailto:zjf...@gmail.com> <mailto: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> > >>>>>>>> >>>> <mailto:ykt...@gmail.com <mailto:ykt...@gmail.com > >> > >>>>>>>> <mailto:ykt...@gmail.com <mailto:ykt...@gmail.com> > >>>>>>>> >>>> <mailto: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> > >>>>>>>> <mailto:ykt...@gmail.com <mailto:ykt...@gmail.com>> > >>>>>>>> >>>> >>>>>>> <mailto:ykt...@gmail.com > >>>>>>>> <mailto:ykt...@gmail.com> <mailto: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> > >>>>>>>> <mailto:imj...@gmail.com <mailto:imj...@gmail.com>> > >>>>>>>> >>>> >>>>>>> <mailto:imj...@gmail.com > >>>>>>>> <mailto:imj...@gmail.com> <mailto: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> > >>>>>>>> <mailto:bowenl...@gmail.com <mailto:bowenl...@gmail.com>> > >>>>>>>> >>>> >>>>>>> <mailto:bowenl...@gmail.com > >>>>>>>> <mailto:bowenl...@gmail.com> > >>>>>>>> >>>> <mailto: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> <mailto:stevenz...@gmail.com > >>>>>>>> <mailto:stevenz...@gmail.com>> > >>>>>>>> >>>> <mailto:stevenz...@gmail.com > >>>>>>>> <mailto:stevenz...@gmail.com> <mailto: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> <mailto:bowenl...@gmail.com > >>>>>>>> <mailto:bowenl...@gmail.com>> > >>>>>>>> >>>> <mailto:bowenl...@gmail.com <mailto: > >> bowenl...@gmail.com > >>>>>>>> <mailto: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> <mailto:bowenl...@gmail.com > >>>>>>>> <mailto:bowenl...@gmail.com>> > >>>>>>>> >>>> <mailto:bowenl...@gmail.com <mailto: > >> bowenl...@gmail.com > >>>>>>>> <mailto: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 > >>>>>>>> >>>> >>>>>>> > >>>>>>>> >>>> >> > >>>>>>>> >>>> > >>>>>>>> >>> > >>>>>>>> >> > >>>>>>>> > >> > >
