> On 23 Mar 2017, at 21:20, Jeff King <p...@peff.net> 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
