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 20:17, Jeff King <peff@xxxxxxxx> wrote:
> 
> On Thu, Mar 23, 2017 at 12:12:15PM -0700, Junio C Hamano wrote:
> 
>> Jeff King <peff@xxxxxxxx> 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 restart an old build, it uses the latest
>>    values. These variables are not automatically available to
>>    forks.
>> 
>> so we should be safe as long as we do not build against PRs.
> 
> 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
for git/git anymore:

"[...] 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

However, I don't think that is a big deal because git/git doesn't
support Pull Requests anyways. Plus, if a contributor is interested
in TravisCI results, then the contributor can setup TravisCI for
their own fork easily.


>> On the other hand, perhaps a contributor may want to build and test
>> his own PR that may affect Windows platform, and such a contributor
>> may be helped if the main repository sets things up to build against
>> PRs.
>> 
>> I personally think it is a separate issue and we shouldn't set it up
>> to build against PRs.  If Windows CI wants to help these
>> contributors, it can give out the token to them, without relying on
>> the travis setup for the main repository.
> 
> Hrm, it does mean that people have no way to test on Windows until the
> branch hits pu. Which is not ideal.

I agree it's not ideal. But I think it is an improvement to check
pu/next/master/maint continuously :-)


Cheers,
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]