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
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.
>>
>>
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
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
> 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
>>>
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
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
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
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
> 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
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:
>>
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
> 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,
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
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
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
> 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
> 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 \
>> +
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
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
> >
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
>
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
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
24 matches
Mail list logo