Hi Peff,
On Thu, 23 Mar 2017, Jeff King wrote:
> 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 (t
On Thu, Mar 23, 2017 at 2:38 PM, Jeff King wrote:
> On Thu, Mar 23, 2017 at 08:26:15PM +0100, Lars Schneider wrote:
>
>> > I think we do build against PRs now. E.g.:
>> >
>> > https://travis-ci.org/git/git/builds/213896051
>> >
>> > But it looks like we can turn that off.
>>
>> When we add a secr
On Thu, Mar 23, 2017 at 09:39:14PM +0100, Lars Schneider wrote:
> > 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
On Thu, Mar 23, 2017 at 01:30:41PM -0700, Junio C Hamano wrote:
> >> 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 t
> On 23 Mar 2017, at 21:20, Jeff King 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 s
Jeff King writes:
>> 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
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 Windo
Lars Schneider writes:
> Things, that would need to be done:
> * Someone with write access to https://travis-ci.org/git/git would need
> to add the secret token as "GFW_CI_TOKEN" variable in the TravisCI
> repository setting [1]. Afterwards the build should just work.
As coordinating the tim
Lars Schneider writes:
>>> I agree it's not ideal. But I think it is an improvement to check
>>> pu/next/master/maint continuously :-)
>>
>> I am not sure what you mean. We are building each and every branch
>> updates already, and I do not see any improvement over what we are
>> doing now. Ca
> On 23 Mar 2017, at 20:38, Jeff King wrote:
>
> On Thu, Mar 23, 2017 at 08:26:15PM +0100, Lars Schneider wrote:
>
>>> I think we do build against PRs now. E.g.:
>>>
>>> https://travis-ci.org/git/git/builds/213896051
>>>
>>> But it looks like we can turn that off.
>>
>> When we add a secret
On Thu, Mar 23, 2017 at 08:26:15PM +0100, Lars Schneider wrote:
> > I think we do build against PRs now. E.g.:
> >
> > https://travis-ci.org/git/git/builds/213896051
> >
> > But it looks like we can turn that off.
>
> When we add a secret variable, then TravisCI will not build Pull Requests
>
> On 23 Mar 2017, at 20:30, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>> "[...] we do not provide these values to untrusted builds,
>> triggered by pull requests from another repository."
>>
>> See:
>> https://docs.travis-ci.com/user/environment-variables/#Defining-Variables-in-Rep
Lars Schneider writes:
> "[...] we do not provide these values to untrusted builds,
> triggered by pull requests from another repository."
>
> See:
> https://docs.travis-ci.com/user/environment-variables/#Defining-Variables-in-Repository-Settings
OK, it is a releaf to see an indication that so
> On 23 Mar 2017, at 20:17, Jeff King wrote:
>
> On Thu, Mar 23, 2017 at 12:12:15PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>>> For instance, if it's in the environment, can I push up a branch that
>>> does "set | grep GFW_CI_TOKEN", open a PR, and see it? I don't know the
>>>
On Thu, Mar 23, 2017 at 12:12:15PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > For instance, if it's in the environment, can I push up a branch that
> > does "set | grep GFW_CI_TOKEN", open a PR, and see it? I don't know the
> > answer.
>
> I think the documentation said
>
> Var
Jeff King writes:
> I think both Junio and I have access to the Travis config. Travis does
> have a "this is secret" flag for setup config. But I think we'd need to
> verify that running the Travis build does not leak the variable in any
> other way.
I am not sure if I want to "Authorize applica
Jeff King writes:
> For instance, if it's in the environment, can I push up a branch that
> does "set | grep GFW_CI_TOKEN", open a PR, and see it? I don't know the
> answer.
I think the documentation said
Variables defined in repository settings are the same for all
builds, and when you
> On 22 Mar 2017, at 20:29, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>> Therefore, we did the following:
>> * Johannes Schindelin set up a Visual Studio Team Services build
>> sponsored by Microsoft and made it accessible via an Azure Function
>> that speaks a super-simple API. We
> On 22 Mar 2017, at 16:49, Johannes Schindelin
> wrote:
>
> Hi Lars,
>
> On Wed, 22 Mar 2017, Lars Schneider wrote:
...
>> +
>> +gfwci () {
>> +curl \
>> +-H "Authentication: Bearer $TOKEN" \
>> +--silent --retry 5 \
>> +"https://git-for-windows-ci.azur
On Thu, Mar 23, 2017 at 05:22:51PM +0100, Johannes Schindelin wrote:
> > The benefit is that Windows CI does not have to subscribe to the
> > GitHub repository to get notified (instead uses Travis as a relay
> > for update notification) and the result can be seen at the same
> > place as results o
Hi Junio,
On Wed, 22 Mar 2017, Junio C Hamano wrote:
> Lars Schneider writes:
>
> > Therefore, we did the following:
> > * Johannes Schindelin set up a Visual Studio Team Services build
> > sponsored by Microsoft and made it accessible via an Azure Function
> > that speaks a super-simple AP
Lars Schneider writes:
> Therefore, we did the following:
> * Johannes Schindelin set up a Visual Studio Team Services build
> sponsored by Microsoft and made it accessible via an Azure Function
> that speaks a super-simple API. We made TravisCI use this API to
> trigger a build, wait until
Hi Lars,
On Wed, 22 Mar 2017, Lars Schneider wrote:
> Things, that might need to be done:
> * The Windows box can only process a single build at a time. A second
> Windows build would need to wait until the first finishes. This
> waiting time and the build time after the wait could exceed the
23 matches
Mail list logo
