Hello,
Yesterday I have restricted the tox Jenkins jobs to only be run by whitelisted person. That is rather inconvenient :-(
To whitelist a person, its Gerrit email address would have to be added to integration/config.git zuul/layout.yaml in a list and in a huge regex.
I have a patch pending that I have yet to test, which would cause test to run when a whitelisted person votes CR+1 and the patch hasn't been tested yet. That would help a lot. The patch is:
https://gerrit.wikimedia.org/r/#/c/184886/
I have no idea when I will get to polish it up and deploy it though :(
Okay this might sound like a stupid question, but how can we test it?
And just for clarification, when someone uploads a patch, not the e-mail in the git commit are important but the account which you used to push it to the repository? Couldn't you automatically generate a list automatically from the admins (or +2able contributors?) of the project? And why is it okay to run the test on a CR+1 vote (which is afaik everyone with an account) but not on push?
2015-01-15 11:44 GMT+01:00 Antoine Musso hashar+wmf@free.fr:
Hello,
Yesterday I have restricted the tox Jenkins jobs to only be run by whitelisted person. That is rather inconvenient :-(
To whitelist a person, its Gerrit email address would have to be added to integration/config.git zuul/layout.yaml in a list and in a huge regex.
I have a patch pending that I have yet to test, which would cause test to run when a whitelisted person votes CR+1 and the patch hasn't been tested yet. That would help a lot. The patch is:
https://gerrit.wikimedia.org/r/#/c/184886/
I have no idea when I will get to polish it up and deploy it though :(
-- Antoine "hashar" Musso
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
On 15 January 2015 at 13:02, Fabian Neundorf CommodoreFabianus@gmx.de wrote:
And just for clarification, when someone uploads a patch, not the e-mail in the git commit are important but the account which you used to push it to the repository?
Yes, the account used to submit the Gerrit changeset.
Couldn't you automatically generate a list automatically from the admins (or +2able contributors?) of the project?
And why is it okay to run the test on a CR+1 vote (which is
afaik everyone with an account) but not on push?
The test are triggered on a +1 from /whitelisted accounts/.
The list of whitelisted accounts is here: https://github.com/wikimedia/integration-config/blob/master/zuul/layout.yaml...
As a workaround, posting 'recheck' should also trigger the tests. Antoine, maybe it's an idea to also trigger on comments that start with 'check' (instead of 'only contain recheck')? That might be easier to implement than your +1 solution.
Merlijn
But according to https://gerrit.wikimedia.org/r/184967 it shouldn't trigger them. And okay didn't saw that only trusted accounts would be considered for +1.
And is there no way to have some tests executed even from not trusted accounts or is that security wise impossible?
2015-01-15 13:33 GMT+01:00 Merlijn van Deen valhallasw@arctus.nl:
On 15 January 2015 at 13:02, Fabian Neundorf CommodoreFabianus@gmx.de wrote:
And just for clarification, when someone uploads a patch, not the e-mail in the git commit are important but the account which you used to push it to the repository?
Yes, the account used to submit the Gerrit changeset.
Couldn't you automatically generate a list automatically from the admins (or +2able contributors?) of the project?
And why is it okay to run the test on a CR+1 vote (which is afaik everyone with an account) but not on push?
The test are triggered on a +1 from /whitelisted accounts/.
The list of whitelisted accounts is here: https://github.com/wikimedia/integration-config/blob/master/zuul/layout.yaml...
As a workaround, posting 'recheck' should also trigger the tests. Antoine, maybe it's an idea to also trigger on comments that start with 'check' (instead of 'only contain recheck')? That might be easier to implement than your +1 solution.
Merlijn
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
Okay and I don't want to beg for 'trusted' status, but this basically means that any C+2able user which isn't trusted can't really C+2 entries. Or does a C+2 start jenkins?
2015-01-15 17:29 GMT+01:00 Fabian Neundorf CommodoreFabianus@gmx.de:
But according to https://gerrit.wikimedia.org/r/184967 it shouldn't trigger them. And okay didn't saw that only trusted accounts would be considered for +1.
And is there no way to have some tests executed even from not trusted accounts or is that security wise impossible?
2015-01-15 13:33 GMT+01:00 Merlijn van Deen valhallasw@arctus.nl:
On 15 January 2015 at 13:02, Fabian Neundorf CommodoreFabianus@gmx.de wrote:
And just for clarification, when someone uploads a patch, not the e-mail in the git commit are important but the account which you used to push it to the repository?
Yes, the account used to submit the Gerrit changeset.
Couldn't you automatically generate a list automatically from the admins (or +2able contributors?) of the project?
And why is it okay to run the test on a CR+1 vote (which is afaik everyone with an account) but not on push?
The test are triggered on a +1 from /whitelisted accounts/.
The list of whitelisted accounts is here: https://github.com/wikimedia/integration-config/blob/master/zuul/layout.yaml...
As a workaround, posting 'recheck' should also trigger the tests. Antoine, maybe it's an idea to also trigger on comments that start with 'check' (instead of 'only contain recheck')? That might be easier to implement than your +1 solution.
Merlijn
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
On 01/15/2015 10:42 AM, Fabian Neundorf wrote:
Okay and I don't want to beg for 'trusted' status, but this basically means that any C+2able user which isn't trusted can't really C+2 entries. Or does a C+2 start jenkins?
+2 will still trigger the submit jobs, regardless of whether you are whitelisted or not.
I submitted[1] to add you to the whitelist. We should also make sure that all of the other people with +2 in Pywikibot are whitelisted.
[1] https://gerrit.wikimedia.org/r/185219
-- Legoktm
You might as well add the missing ones to that same patch then.
Mpaa
On Thu, Jan 15, 2015 at 8:00 PM, Legoktm legoktm.wikipedia@gmail.com wrote:
On 01/15/2015 10:42 AM, Fabian Neundorf wrote:
Okay and I don't want to beg for 'trusted' status, but this basically means that any C+2able user which isn't trusted can't really C+2 entries. Or does a C+2 start jenkins?
+2 will still trigger the submit jobs, regardless of whether you are whitelisted or not.
I submitted[1] to add you to the whitelist. We should also make sure that all of the other people with +2 in Pywikibot are whitelisted.
[1] https://gerrit.wikimedia.org/r/185219
-- Legoktm
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l
Le 15/01/2015 17:29, Fabian Neundorf a écrit :
But according to https://gerrit.wikimedia.org/r/184967 it shouldn't trigger them. And okay didn't saw that only trusted accounts would be considered for +1.
And is there no way to have some tests executed even from not trusted accounts or is that security wise impossible?
We will be able one day. We want to run the Jenkins jobs in isolated/disposable instances booted on an OpenStack cloud (ie WMF labs).
I wrote this week a first draft of the envisioned architecture at:
https://www.mediawiki.org/wiki/Continuous_integration/Architecture/Isolation
It is surely going to take a few rounds to get it setup though.
This may sound stupid, but... why can't jobs be run by patch submitters?
Il 15/01/2015 11:44, Antoine Musso ha scritto:
Hello,
Yesterday I have restricted the tox Jenkins jobs to only be run by whitelisted person. That is rather inconvenient :-(
To whitelist a person, its Gerrit email address would have to be added to integration/config.git zuul/layout.yaml in a list and in a huge regex.
I have a patch pending that I have yet to test, which would cause test to run when a whitelisted person votes CR+1 and the patch hasn't been tested yet. That would help a lot. The patch is:
https://gerrit.wikimedia.org/r/#/c/184886/
I have no idea when I will get to polish it up and deploy it though :(
On 15 January 2015 at 21:42, Ricordisamoa ricordisamoa@openmailbox.org wrote:
This may sound stupid, but... why can't jobs be run by patch submitters?
Because they would effectively get full (user-level) access on the unit test servers. It's basically a check to prevent non-trusted users (after all, registration is completely open) from running potentially malicious code. People on the 'OK' list are expected to not submit malicious code to begin with ;-)
Merlijn
So, what would it take to make +2 people automatically 'trusted'?
Il 15/01/2015 22:40, Merlijn van Deen ha scritto:
On 15 January 2015 at 21:42, Ricordisamoa <ricordisamoa@openmailbox.org mailto:ricordisamoa@openmailbox.org> wrote:
This may sound stupid, but... why can't jobs be run by patch submitters?Because they would effectively get full (user-level) access on the unit test servers. It's basically a check to prevent non-trusted users (after all, registration is completely open) from running potentially malicious code. People on the 'OK' list are expected to not submit malicious code to begin with ;-)
Merlijn
Hi.
Is there anyone taking care of extending whitelist to +2? It is very convenient to see test results after submitting a patch.
Mpaa
On Fri, Jan 16, 2015 at 2:45 AM, Ricordisamoa ricordisamoa@openmailbox.org wrote:
So, what would it take to make +2 people automatically 'trusted'?
Il 15/01/2015 22:40, Merlijn van Deen ha scritto:
On 15 January 2015 at 21:42, Ricordisamoa ricordisamoa@openmailbox.org wrote:
This may sound stupid, but... why can't jobs be run by patch submitters?
Because they would effectively get full (user-level) access on the unit test servers. It's basically a check to prevent non-trusted users (after all, registration is completely open) from running potentially malicious code. People on the 'OK' list are expected to not submit malicious code to begin with ;-)
Merlijn
Pywikipedia-l mailing list Pywikipedia-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l