impala-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Behm <alex.b...@cloudera.com>
Subject Re: Jenkins jobs to verify patches
Date Wed, 14 Dec 2016 21:38:47 GMT
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.

On Wed, Dec 14, 2016 at 1:33 PM, Bharath Vissapragada <bharathv@cloudera.com
> 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 <
> tbobrovytsky@cloudera.com> 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 <alex.behm@cloudera.com>
> > 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 <
> tarmstrong@cloudera.com>
> > > 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 <alex.behm@cloudera.com>
> > > 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 <
> > > tarmstrong@cloudera.com>
> > > > > 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 <jbapple@cloudera.com
> >
> > > > 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.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message