<div dir="ltr"><div><div><div>Hi Karanbir,<br><br></div>what advantages does <a href="http://ci.centos.org">ci.centos.org</a> have over current infrastructure? Why to use JJB and not new Pipeline plugin?<br><br></div>Regards,<br></div>Pavol<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 22, 2016 at 2:42 PM, Max Rydahl Andersen <span dir="ltr"><<a href="mailto:manderse@redhat.com" target="_blank">manderse@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 22 Aug 2016, at 14:31, Karanbir Singh wrote:<br>
<br>
> On 22/08/16 13:18, Max Rydahl Andersen wrote:<br>
>> With JJB, there are 2 types of jobs: 1) the service job that will<br>
>> typically run on schedule. This job will then parse the<br>
>> devtools-ci-index.git repo and setup jenkins jobs, change configs<br>
>> and notification details etc for the actual jobs. I think leaving<br>
>> that on a 10 min cron might be ok.<br>
>><br>
>> I assume the reasons for 10 min cron vs building on change is to<br>
>> ensure manual edits in jenkins UI do not stay in effect by accident<br>
>> ?<br>
><br>
> yeah - do not want anyone manually doing anything once the service job<br>
> has been run the first time. Also sometimes - based on the job time it<br>
> can take jenkins a bit of time to sync the configs through as well. So<br>
> its worth having the role/job get rebuilt in 10 min again to make<br>
> sure. Having said this, I've not seen a need for it in a while.<br>
><br>
> The more pedantic(I like, if we can do this), is to have a JJB<br>
> validation job run on per-commit. So that when the service job kicks<br>
> in, its always going to work with a known good ( and locally<br>
> consumable.. JJB def ). This also helps validate that all plugins are<br>
> available, right version etc.<br>
<br>
</span>sounds like a nice improvement if doable eventually - even better if possible<br>
to validate this in PR for the repo; but not sure if that validation<br>
will have side effects ?<br>
<span class=""><br>
>> 2) the actual build jobs : I have a little PoC job there, let me<br>
>> try and adapt that for the almighty-core and demonstrate the<br>
>> github integration. We typically use the github webhooks to setup a<br>
>> notify task into jenkins rather than the other way around. This has<br>
>> quite a few advantages in that we can accept different kind of<br>
>> notify's and do different operations based on those - however, it<br>
>> does come with the downside that the ci-centos user needs to be<br>
>> added into the contributors for the git repos in <a href="http://github.com" rel="noreferrer" target="_blank">github.com</a>. If<br>
>> this isnt seen as a major problem, it would be the easiest, fastest<br>
>> path to take.<br>
>><br>
>> We can add that if it is necessary - but is there any plans of<br>
>> having ci-centos have project specific users rather than global<br>
>> ci-centos users ?<br>
><br>
> There is an action item to work with this, but looking through the<br>
> stack its not actually prioritised.  Let me try and see if we can vote<br>
> that up a bit.<br>
<br>
</span>okey, cool - but as said, not a blocker. if giving ci-cents user access<br>
makes it move faster lets do it.<br>
<br>
You are admin on the repos now afaik so just do it if need be.<br>
<br>
/max<br>
<a href="http://about.me/maxandersen" rel="noreferrer" target="_blank">http://about.me/maxandersen</a><br>
<div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
almighty-public mailing list<br>
<a href="mailto:almighty-public@redhat.com">almighty-public@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/almighty-public" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/almighty-<wbr>public</a><br>
</div></div></blockquote></div><br></div>