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
Most Git developers work on Linux and they have no way to know if their
changes would break the Git for Windows build. Let's fix that by adding
a job to TravisCI that builds and tests Git on Windows. Unfortunately,
TravisCI does not support Windows.
Therefore, we did the following:
* Johannes Schi
24 matches
Mail list logo
