As discussed in the thread, requiring the use of gerrit provides an
auditing method - the code must at least be posted there, so if
something goes haywire we can see the code that caused it.

However, you can post a draft if the code is not yet ready for review.
the Jenkins job can test your draft.

On Thu, Jan 5, 2017 at 4:13 AM, Lars Volker <[email protected]> wrote:
> Is it possible without much effort to make this work on github urls, too?
> Currently our policy seems to be that we pick up reviews as soon as they're
> posted, so there doesn't seem to be a way for non-Cloudera non-committers
> to run tests on Jenkins before submitting a change for review.
>
> On Thu, Jan 5, 2017 at 3:02 AM, Jim Apple <[email protected]> wrote:
>
>> http://jenkins.impala.io:8080/job/pre-review-test/ is now open for
>> business.
>>
>> On Tue, Jan 3, 2017 at 3:53 PM, Jim Apple <[email protected]> wrote:
>> > Given that sentiment, I'll plan on opening up a limited-parallelism
>> > job for anonymous users that only allows gerrit patches.
>> >
>> > I will also plan the switchover to happen on January 9, six days from
>> > today. On that day, I'll turn off the Cloudera-VPN-gated pre-merge
>> > job.
>> >
>> > 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.
>> >>>
>>

Reply via email to