On Wed, Dec 14, 2016 at 1:38 PM, Alex Behm <[email protected]> wrote:
> That integration sounds like a great idea to me. > > Just to clarify the purpose: We'd like external contributors to be able to > run private build+test runs during development, and not just run GVO once > the patch has +2. The hard part is gettig the patch to +2 in the first > place and we've seen instances where relying on local test runs only can be > difficult. > > For example, contributors could upload a draft to gerrit and run a private > build to fix problems before publishing the patch fir review. > As per this [1] link, I think that can be configured. I haven't tried it myself, but from the looks of it, it seems plausible. [1] https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger#GerritTrigger-TriggerConfiguration > > On Wed, Dec 14, 2016 at 1:33 PM, Bharath Vissapragada < > [email protected] > > wrote: > > > Just wondering why we can't link Jenkins authentication with gerrit login > > in this case instead of having two separate login credentials. That way > we > > can retain the audit trail of the jobs and also isolate Jenkins to only > run > > code thats approved (+2ed) over gerrit. With this, any new contributor > > (whoever has signed up on gerrit) can have access to the jenkins box and > we > > can be sure that they only run the stuff that is approved by committers. > > Thoughts? > > > > * I'm not totally sure if such an integration is possible but I did a > quick > > search and I got a feeling that shouldn't be difficult. > > > > On Wed, Dec 14, 2016 at 1:18 PM, Taras Bobrovytsky < > > [email protected]> wrote: > > > > > I would be more in favor of starting with open access instead of having > > to > > > hand out credentials. It's both less work for us and it makes it easier > > to > > > contribute. If we notice that this is not working well, or gets abused, > > we > > > can switch to what Tim is suggesting. Also, we should be able to see > who > > is > > > using our Jenkins by looking at Gerrit (because the patch must be > > uploaded > > > to Gerrit before starting a build). > > > > > > On Wed, Dec 14, 2016 at 10:57 AM, Alex Behm <[email protected]> > > > wrote: > > > > > > > I'm fine with Tim's approach, but it does add some friction to > > > > contributions. > > > > > > > > On Wed, Dec 14, 2016 at 9:57 AM, Tim Armstrong < > > [email protected]> > > > > wrote: > > > > > > > > > I mean the contributor could email an email address (e.g. a mailing > > > list) > > > > > asking for credentials and we could email them privately. > > > > > > > > > > Do we know what other Apache projects do for situations like this? > > > > > > > > > > On Wed, Dec 14, 2016 at 9:18 AM, Alex Behm <[email protected] > > > > > > wrote: > > > > > > > > > > > Can you clarify the "credentials by mailing list" approach? > > > > > > > > > > > > If we send out the credentials on a public list, it's pretty > close > > to > > > > > open > > > > > > access. > > > > > > > > > > > > If we send out credentials to contributors privately, we have an > > > > > additional > > > > > > hurdle to contributions. > > > > > > > > > > > > On Wed, Dec 14, 2016 at 9:12 AM, Tim Armstrong < > > > > [email protected]> > > > > > > wrote: > > > > > > > > > > > > > Got it. > > > > > > > > > > > > > > I think I'd probably be more in favour of handing out login > > > > credential > > > > > to > > > > > > > contributors on demand (e.g. by mailing a list) rather than > > having > > > > > open > > > > > > > access, just so we have a clearer idea of who's using it. I > don't > > > > have > > > > > a > > > > > > > strong objection to the alternative. > > > > > > > > > > > > > > On Wed, Dec 14, 2016 at 8:52 AM, Jim Apple < > [email protected] > > > > > > > > wrote: > > > > > > > > > > > > > > > > How isolated is the Jenkins instance? > > > > > > > > > > > > > > > > As far as I know, the workers have little access to the > > > > coordinator. > > > > > > See > > > > > > > > here: > > > > > > > > > > > > > > > > https://wiki.jenkins-ci.org/display/JENKINS/Slave+To+ > > > > > > > Master+Access+Control > > > > > > > > > > > > > > > > This flag is on and there are no whitelisted exceptions. > > > > > > > > > > > > > > > > > Does the jenkins user have many privileges on the VM? > > > > > > > > > > > > > > > > They have passwordless sudo on the worker > > > > > > > > > > > > > > > > > Could it simply wipe > > > > > > > > > out the job history to destroy the trail? > > > > > > > > > > > > > > > > Job history is stored on the coordinator. > > > > > > > > > > > > > > > > > Jenkins also presumably has > > > > > > > > > credentials to make at least some changes to gerrit - are > > those > > > > > > > > privileges > > > > > > > > > restrictive enough that it couldn't cause problems there > too? > > > > > > > > > > > > > > > > Those are stored only on the coordinator and cannot be used > by > > > the > > > > > > > slaves. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
