You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@reef.apache.org by Boris Shulman <sh...@gmail.com> on 2016/02/29 23:41:30 UTC
Travis CI buils
With the addition of openjdk 7 our CI builds take more then 60 minutes to
run. Do we really need this?
I would say that we should stay with single JDK validation until we will be
able to increase parallelism of our test. Currently it just takes too long.
WDYT?
Boris.
Re: Travis CI buils
Posted by Dongjoon Hyun <do...@apache.org>.
I hope so, but I'm not. :(
The real owner is Apache INFRA team. They set up for us.
Recently, I became a member of Apache Foundation in Github organization
to acquire such permissions (Travis-CI, DockerHub, and so on), but up to
now,
there is no difference.
If I get some, I will announce @private.
Dongjoon.
On Mon, Feb 29, 2016 at 3:39 PM, Mariia Mykhailova <ma...@microsoft.com>
wrote:
> I see options like cancel/restart build on
> https://travis-ci.org/tcNickolas/reef/ for which I'm owner. I don't know
> who has that kind of access for apache/reef. Maybe Dongjoon, since he set
> up the CI itself in REEF-816?
>
> -Mariia
>
> -----Original Message-----
> From: Markus Weimer [mailto:markus@weimo.de]
> Sent: Monday, February 29, 2016 3:35 PM
> To: dev@reef.apache.org
> Subject: Re: Travis CI buils
>
> On 2016-02-29 15:27, Boris Shulman wrote:
> > The problem is that during this 22 hours we can have multiple check
> > ins each of them will trigger a CI build, correct?
>
> Yes, that is a bit of a problem. It would be nice if we could cancel the
> builds in the queue that are not referring to the current state of the PR
> any more.
>
> That said, most pull requests have a couple of hours between commits
> during the review phase anyhow. It doesn't matter often that way.
> However, right now it matters because we (a) have a PR with lots of
> commits during the reviews and (b) have a related PR we'd like to get in
> before that one. This isn't our usual situation.
>
> Does anyone know how to cancel builds, though?
>
> Markus
>
RE: Travis CI buils
Posted by Mariia Mykhailova <ma...@microsoft.com>.
I see options like cancel/restart build on https://travis-ci.org/tcNickolas/reef/ for which I'm owner. I don't know who has that kind of access for apache/reef. Maybe Dongjoon, since he set up the CI itself in REEF-816?
-Mariia
-----Original Message-----
From: Markus Weimer [mailto:markus@weimo.de]
Sent: Monday, February 29, 2016 3:35 PM
To: dev@reef.apache.org
Subject: Re: Travis CI buils
On 2016-02-29 15:27, Boris Shulman wrote:
> The problem is that during this 22 hours we can have multiple check
> ins each of them will trigger a CI build, correct?
Yes, that is a bit of a problem. It would be nice if we could cancel the builds in the queue that are not referring to the current state of the PR any more.
That said, most pull requests have a couple of hours between commits during the review phase anyhow. It doesn't matter often that way.
However, right now it matters because we (a) have a PR with lots of commits during the reviews and (b) have a related PR we'd like to get in before that one. This isn't our usual situation.
Does anyone know how to cancel builds, though?
Markus
RE: Travis CI buils
Posted by Mariia Mykhailova <ma...@microsoft.com>.
Looking at the queue, each build has two associated times: total time, which indeed increased with addition of 3rd build job, and elapsed time, which stayed approximately the same. Build jobs of one build run in parallel, so addition of one more job to each build doesn't affect our observed build time dramatically.
The period of inactivity between builds is another issue, but it doesn't look like we can influence it.
-Mariia
-----Original Message-----
From: Markus Weimer [mailto:markus@weimo.de]
Sent: Monday, February 29, 2016 3:35 PM
To: dev@reef.apache.org
Subject: Re: Travis CI buils
On 2016-02-29 15:27, Boris Shulman wrote:
> The problem is that during this 22 hours we can have multiple check
> ins each of them will trigger a CI build, correct?
Yes, that is a bit of a problem. It would be nice if we could cancel the builds in the queue that are not referring to the current state of the PR any more.
That said, most pull requests have a couple of hours between commits during the review phase anyhow. It doesn't matter often that way.
However, right now it matters because we (a) have a PR with lots of commits during the reviews and (b) have a related PR we'd like to get in before that one. This isn't our usual situation.
Does anyone know how to cancel builds, though?
Markus
Re: Travis CI buils
Posted by Markus Weimer <ma...@weimo.de>.
On 2016-02-29 15:27, Boris Shulman wrote:
> The problem is that during this 22 hours we can have multiple check ins
> each of them will trigger a CI build, correct?
Yes, that is a bit of a problem. It would be nice if we could cancel the
builds in the queue that are not referring to the current state of the
PR any more.
That said, most pull requests have a couple of hours between commits
during the review phase anyhow. It doesn't matter often that way.
However, right now it matters because we (a) have a PR with lots of
commits during the reviews and (b) have a related PR we'd like to get in
before that one. This isn't our usual situation.
Does anyone know how to cancel builds, though?
Markus
Re: Travis CI buils
Posted by Markus Weimer <ma...@weimo.de>.
On 2016-02-29 15:28, Boris Shulman wrote:
> I noticed it actually took CI 30 minutes to start a new build. For
> 30 minutes it did nothing.
Travis has us in a "fair use" category. That makes it perfectly
acceptable for them to not run anything for us at a given point in time.
That said, I don't think that is what happened. Travis also builds
current `master`, whenever that moves forward:
https://travis-ci.org/apache/reef/branches
I believe we had a commit recently, so that made it into the queue as well.
Markus
Re: Travis CI buils
Posted by Boris Shulman <sh...@gmail.com>.
I noticed it actually took CI 30 minutes to start a new build. For 30
minutes it did nothing.
On Mon, Feb 29, 2016 at 3:27 PM, Boris Shulman <sh...@gmail.com> wrote:
> The problem is that during this 22 hours we can have multiple check ins
> each of them will trigger a CI build, correct? So it looks like if we have
> multiple PRs and each of them can have multiple builds we can delay our PRs
> quite a lot. Also it looks like something bad going on with build itself.
> Looking on the queue nothing is actually building right now and we have 4
> outstanding builds...
>
> On Mon, Feb 29, 2016 at 3:09 PM, Mariia Mykhailova <mamykhai@microsoft.com
> > wrote:
>
>> Travis CI is very useful for catching issues which do not manifest during
>> local tests, especially transient ones (for example, REEF-1040 which was
>> coming from a bug in suspend-resubmit logic).
>>
>> According to http://issuestats.com/github/apache/reef, our average time
>> to close PR is ~22 hours. Do we want to reduce our test coverage for the
>> sake of 30 minutes gain? I feel we should invest in speeding up tests
>> (which will also improve lives of developers who run tests on their local
>> machine).
>>
>> @Markus: I'll check, but I suspect we might be limited to 1 VM by our
>> free account status. VM itself has 1.5 cores, so some optimization there is
>> also possible.
>>
>> -Mariia
>>
>> -----Original Message-----
>> From: Markus Weimer [mailto:markus@weimo.de]
>> Sent: Monday, February 29, 2016 3:01 PM
>> To: dev@reef.apache.org
>> Subject: Re: Travis CI buils
>>
>> On 2016-02-29 14:41, Boris Shulman wrote:
>> > With the addition of openjdk 7 our CI builds take more then 60 minutes
>> > to run. Do we really need this?
>>
>> We should test on (open)jdk 7. Other tests are somewhat optional. Is
>> there a way for us to increase parallelism on Travis?
>>
>> Markus
>>
>
>
Re: Travis CI buils
Posted by Boris Shulman <sh...@gmail.com>.
The problem is that during this 22 hours we can have multiple check ins
each of them will trigger a CI build, correct? So it looks like if we have
multiple PRs and each of them can have multiple builds we can delay our PRs
quite a lot. Also it looks like something bad going on with build itself.
Looking on the queue nothing is actually building right now and we have 4
outstanding builds...
On Mon, Feb 29, 2016 at 3:09 PM, Mariia Mykhailova <ma...@microsoft.com>
wrote:
> Travis CI is very useful for catching issues which do not manifest during
> local tests, especially transient ones (for example, REEF-1040 which was
> coming from a bug in suspend-resubmit logic).
>
> According to http://issuestats.com/github/apache/reef, our average time
> to close PR is ~22 hours. Do we want to reduce our test coverage for the
> sake of 30 minutes gain? I feel we should invest in speeding up tests
> (which will also improve lives of developers who run tests on their local
> machine).
>
> @Markus: I'll check, but I suspect we might be limited to 1 VM by our free
> account status. VM itself has 1.5 cores, so some optimization there is also
> possible.
>
> -Mariia
>
> -----Original Message-----
> From: Markus Weimer [mailto:markus@weimo.de]
> Sent: Monday, February 29, 2016 3:01 PM
> To: dev@reef.apache.org
> Subject: Re: Travis CI buils
>
> On 2016-02-29 14:41, Boris Shulman wrote:
> > With the addition of openjdk 7 our CI builds take more then 60 minutes
> > to run. Do we really need this?
>
> We should test on (open)jdk 7. Other tests are somewhat optional. Is there
> a way for us to increase parallelism on Travis?
>
> Markus
>
RE: Travis CI buils
Posted by Mariia Mykhailova <ma...@microsoft.com>.
Travis CI is very useful for catching issues which do not manifest during local tests, especially transient ones (for example, REEF-1040 which was coming from a bug in suspend-resubmit logic).
According to http://issuestats.com/github/apache/reef, our average time to close PR is ~22 hours. Do we want to reduce our test coverage for the sake of 30 minutes gain? I feel we should invest in speeding up tests (which will also improve lives of developers who run tests on their local machine).
@Markus: I'll check, but I suspect we might be limited to 1 VM by our free account status. VM itself has 1.5 cores, so some optimization there is also possible.
-Mariia
-----Original Message-----
From: Markus Weimer [mailto:markus@weimo.de]
Sent: Monday, February 29, 2016 3:01 PM
To: dev@reef.apache.org
Subject: Re: Travis CI buils
On 2016-02-29 14:41, Boris Shulman wrote:
> With the addition of openjdk 7 our CI builds take more then 60 minutes
> to run. Do we really need this?
We should test on (open)jdk 7. Other tests are somewhat optional. Is there a way for us to increase parallelism on Travis?
Markus
Re: Travis CI buils
Posted by Markus Weimer <ma...@weimo.de>.
On 2016-02-29 14:41, Boris Shulman wrote:
> With the addition of openjdk 7 our CI builds take more then 60 minutes to
> run. Do we really need this?
We should test on (open)jdk 7. Other tests are somewhat optional. Is
there a way for us to increase parallelism on Travis?
Markus