Re: Checkout of web-platform-tests pull request

Le mercredi 10 avril 2013 à 21:02 +0200, James Graham a écrit :
> > They have been checked out in
> > https://w3c-test.org/web-platform-tests/submissions/ using the labels of
> > the pull requests as the directory name (look at how many ways one can
> > spell "w3c:submission").
> 
> Could we just use the pull request number as the directory name?

I thought the pull request labels were more informative than their
numbers, but I don't really mind either way. (it's in fact somewhat
easier for me to deal with numbers)

> > At least one submission checkout didn't succeed due to conflicts in
> > merging (https://github.com/w3c/web-platform-tests/pull/44)
> 
> How can a checkout have merge conflicts? That isn't making any sense to 
> me. Unless you are trying to auto-rebase onto master and them checkout. 
> That doesn't seem like a good idea though.

The script I have been using (git-pull-request) tries to merge pull
requests in, hence the conflict; that's easy to fix though.

> > The discussion in #webapps had alluded to something more automated (e.g.
> > automatic checkout each time a pull request is made), but I didn't
> > manage to find a reasonable security approach within what the github API
> > offers; meanwhile, I expect a manual approach will work fine for now,
> > and I expect a more involved review system will provide a more automated
> > approach in the future.
> 
> I don't think a manual approach is going to scale.

What scaling are you thinking of? In the number of submissions? In the
number of updates to existing pull requests?

For the former, I think the scale of new submissions is likely to remain
low until we have a better deployed infrastrcture.

For the latter, I agree that some automation would be useful; I think a
cron job would probably do.

>  I'm also not sure how 
> the github API is related to security; all the github API is needed for is 
> to get notifications about when there are new pull requests or when the 
> repo is updated.

I was fairly elusive, indeed :) Let me explain what I meant by security
here:
* I wounldn't want any random pull requests from any random person made
on our github repository to result in publishing the content of the said
pull request — this would make it too easy to abuse
* there is the specific case of content including PHP files that need to
be reviewed before being activated
* what I had looked at was to use github issues' assignment and/or
issues' labeling (given that pull requests automatically creates issues)
to make it possible for someone to easily mark a submission as
mirroring-worthy
* but the github API doesn't expose who assigned an issue or labeled it,
making it hard to account for a given decision

>  If the security concern is just PHP files mod_pup should 
> be disabled for the submission/ directory (or, for a more advanced 
> solution, it should be disabled for files that have been changed on the 
> pull request branch).

That would indeed address my bullet #2 above, and I guess assuming that
people who have write access to the repo are trustworthy for #1 is a
no-brainer (given that write access means ability to push content on
master in w3c-test.org), so it might be worth re-assessing that question
in my automation plan :)

Dom

Received on Thursday, 11 April 2013 13:14:26 UTC