Re: [PATCH v1] travis-ci: build and test Git on Windows

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On 23 Mar 2017, at 21:20, Jeff King <peff@xxxxxxxx> wrote:
> 
> On Thu, Mar 23, 2017 at 09:00:33PM +0100, Lars Schneider wrote:
> 
>>> Ah, OK, that makes sense. So we would only have to worry about our _own_
>>> code accidentally disclosing it. But that should be easy to look for by
>>> grepping the log (did somebody do that?).
>> 
>> This is how a successful Windows build would look like:
>> https://travis-ci.org/larsxschneider/git/jobs/214391822
>> 
>> Dscho's token is not in the log.
> 
> Great, thank you for double-checking.

I can see that one could think that this variables leaks, though. 
I think in v2 I won't pass the token as parameter. The token 
variable is an environment variable anyways and I can just use
it in the script.


>>> - I have a lot of work-in-progress branches. I put "-wip" at the end
>>>   of the branch name for my own scripts. It looks like I can put "[ci
>>>   skip]" in the commit subject to convince Travis to skip them, but
>>>   that's a little annoying. Is there any way to skip based on just the
>>>   branch name? I couldn't find one.
>> 
>> We can blacklist these branches with a regex in the travis.yml:
>> https://docs.travis-ci.com/user/customizing-the-build#Building-Specific-Branches
> 
> I had a feeling it might be something like that. So we would all need to
> agree on the convention for WIP branch names. If other people like the
> idea, I'm happy to make a patch, but I don't want to impose my own weird
> conventions on everyone else.

This makes sense to me. If someone complains with a good argument then
we can still revert it.


>> Maybe TravisCI throttles your usage somehow as you push a lot of commits?
> 
> Could be. Looking at:
> 
>  https://travis-ci.org/peff/git/branches
> 
> It seems to timeout on over half the branches (in fact, there are only a
> few that passed all of the tests). My pattern is particularly spiky from
> Travis's perspective, because once a day I rebase everything on top of
> master and push them the whole thing in a bunch. So they 75 branches,
> all at once. That seems like it would be ripe for throttling (though I
> would much rather they just queue the builds and do them one at a time).

Could you try to set this to 7 or less in your TravisCI?
https://docs.travis-ci.com/user/customizing-the-build#Limiting-Concurrent-Builds

I am curious if this improves the situation.

- Lars



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]