github PR builds

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

github PR builds

Stefan Bodewig
Hi

if I understand correctly our current PR build setup with Jenkins
requires somebody to comment on the issue in order to have Jenkins build
it.

Do we really want this extra step? For Commons Compress I never thought
about something like that.

If we do, how does Jenkins know who is allowed to trigger builds? Is
this a list or derived from membership in the apache github organization
or how does it work?

Sorry if this has been discussed before, I simply don't recall it.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: github PR builds

Jaikiran Pai
The PR build on Jenkins is backed by the github PR integration
plugin[1]. One of the features of that plugin is to prevent some
malicious/rogue PR (imagine someone creating a PR with code which does
some odd things with the host on which it runs) being auto-triggered
against the Jenkins hosts. The plugin can be configured to disable this
feature or (like now) be configured to allow a whitelist of users for
whom the job gets triggered when they open a PR. If a user not belonging
to that whitelist opens a PR, then one of the admins (also configurable
in the plugin) can add a "this is ok to test" message (of course after
doing some basic checks about the content of the PR itself) so that the
job gets triggered.

 From what I remember, our Ant job is configured to consider ASF members
as whitelisted and admins, so if some ASF members opens a PR, it
auto-triggers a job and also lets ASF members to put in a "this is ok to
test" message to trigger the job for users who aren't part of the
whitelist or aren't ASF members themselves. I'll re-check the Ant job to
make sure that indeed is how it is configured.

Note that when I say ASF members, I'm talking about github users who
belong to the apache organization.

P.S: There are a few other keywords that the plugin recognizes and is
documented at [1].

[1]
https://wiki.jenkins.io/display/JENKINS/GitHub+pull+request+builder+plugin

-Jaikiran


On 06/02/18 4:59 PM, Stefan Bodewig wrote:

> Hi
>
> if I understand correctly our current PR build setup with Jenkins
> requires somebody to comment on the issue in order to have Jenkins build
> it.
>
> Do we really want this extra step? For Commons Compress I never thought
> about something like that.
>
> If we do, how does Jenkins know who is allowed to trigger builds? Is
> this a list or derived from membership in the apache github organization
> or how does it work?
>
> Sorry if this has been discussed before, I simply don't recall it.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: github PR builds

Jaikiran Pai
So it looks like, although I did send a mail about this PR integration a
while back[1], I did not include the details about this plugin which was
used for the integration. Sorry about that.

[1] https://www.mail-archive.com/dev@.../msg46284.html

-Jaikiran


On 06/02/18 5:12 PM, Jaikiran Pai wrote:

> The PR build on Jenkins is backed by the github PR integration
> plugin[1]. One of the features of that plugin is to prevent some
> malicious/rogue PR (imagine someone creating a PR with code which does
> some odd things with the host on which it runs) being auto-triggered
> against the Jenkins hosts. The plugin can be configured to disable
> this feature or (like now) be configured to allow a whitelist of users
> for whom the job gets triggered when they open a PR. If a user not
> belonging to that whitelist opens a PR, then one of the admins (also
> configurable in the plugin) can add a "this is ok to test" message (of
> course after doing some basic checks about the content of the PR
> itself) so that the job gets triggered.
>
> From what I remember, our Ant job is configured to consider ASF
> members as whitelisted and admins, so if some ASF members opens a PR,
> it auto-triggers a job and also lets ASF members to put in a "this is
> ok to test" message to trigger the job for users who aren't part of
> the whitelist or aren't ASF members themselves. I'll re-check the Ant
> job to make sure that indeed is how it is configured.
>
> Note that when I say ASF members, I'm talking about github users who
> belong to the apache organization.
>
> P.S: There are a few other keywords that the plugin recognizes and is
> documented at [1].
>
> [1]
> https://wiki.jenkins.io/display/JENKINS/GitHub+pull+request+builder+plugin
>
> -Jaikiran
>
>
> On 06/02/18 4:59 PM, Stefan Bodewig wrote:
>> Hi
>>
>> if I understand correctly our current PR build setup with Jenkins
>> requires somebody to comment on the issue in order to have Jenkins build
>> it.
>>
>> Do we really want this extra step? For Commons Compress I never thought
>> about something like that.
>>
>> If we do, how does Jenkins know who is allowed to trigger builds? Is
>> this a list or derived from membership in the apache github organization
>> or how does it work?
>>
>> Sorry if this has been discussed before, I simply don't recall it.
>>
>> Stefan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: github PR builds

Stefan Bodewig
In reply to this post by Jaikiran Pai
On 2018-02-06, Jaikiran Pai wrote:

> The PR build on Jenkins is backed by the github PR integration
> plugin[1]. One of the features of that plugin is to prevent some
> malicious/rogue PR (imagine someone creating a PR with code which does
> some odd things with the host on which it runs) being auto-triggered
> against the Jenkins hosts.

I see. It's just that I never saw this in use before - and to be honest
am a bit annoyed by the bot asking for confirmation on every pull
request :-)

> From what I remember, our Ant job is configured to consider ASF
> members as whitelisted and admins, so if some ASF members opens a PR,
> it auto-triggers a job and also lets ASF members to put in a "this is
> ok to test" message to trigger the job for users who aren't part of
> the whitelist or aren't ASF members themselves. I'll re-check the Ant
> job to make sure that indeed is how it is configured.

> Note that when I say ASF members, I'm talking about github users who
> belong to the apache organization.

Thanks. And don't worry about not providing details in your initial
email - I actually don't recall the mail at all and most probably you
provided everything that was needed.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: github PR builds

Jaikiran Pai

On 06/02/18 10:10 PM, Stefan Bodewig wrote:

> On 2018-02-06, Jaikiran Pai wrote:
>
>> The PR build on Jenkins is backed by the github PR integration
>> plugin[1]. One of the features of that plugin is to prevent some
>> malicious/rogue PR (imagine someone creating a PR with code which does
>> some odd things with the host on which it runs) being auto-triggered
>> against the Jenkins hosts.
> I see. It's just that I never saw this in use before - and to be honest
> am a bit annoyed by the bot asking for confirmation on every pull
> request :-)
If it continues to be annoying, please do let me know and I'll disable
this feature on that job.

-Jaikiran


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]