<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 31, 2017 at 7:05 PM, Ari LiVigni <span dir="ltr"><<a href="mailto:alivigni@redhat.com" target="_blank">alivigni@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">As you pointed out Jenkins pipeline is a great fit for this scenario for a number of reasons. <div> - It keeps all the stages in one pipeline with little duplication</div><div> - Great integration with Openshift</div><div><br></div><div>That said I understand having to switch from JJB to Pipeline.</div><div>There is also a way you can start to combine both while still using JJB:</div><div><a href="https://docs.openstack.org/infra/jenkins-job-builder/project_pipeline.html?highlight=pipeline#module-project_pipeline" target="_blank">https://docs.openstack.org/<wbr>infra/jenkins-job-builder/<wbr>project_pipeline.html?<wbr>highlight=pipeline#module-<wbr>project_pipeline</a></div></div></blockquote><div><br></div><div>Very helpful - I've decided to go with this, so I came up with this schema:</div><div><br></div><div><a href="http://pastebin.centos.org/98936/">http://pastebin.centos.org/98936/</a></div><div><br></div><div>Basically I have 3 jobs instead of 1</div><div><br></div><div>1. Main - new, it is a pipeline and kicks off the other jobs</div><div>2. Build - existing, it does what the current job does</div><div>3. Deploy - new, parameterised job so that it does not have to be created N times (where N is number of repos we build)</div><div><br></div><div>The only thing I am not sure about is the deploy job - it might be a bit confusing with the parameters as things may fail "randomly", but I still like it a bit more than adding 30-40 new jobs which do exactly the same thing with just 2 changing variables..</div><div><br></div><div>Does it make sense like this? Would you say it follows "best practices"?:) </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div><br></div><div>Multijob is a good way to keep jobs in a pipeline that allows certain jobs to run in parallel and then gate on a final step.</div><div>I do believe this can fit what you are looking for. If you need to run multiple similar scenarios of the same steps with subtle config differences than matrix-jobs are great as well.</div><div><br></div><div>I did a blog post on this of how we used this. We use it for Openshift-ansible committed and PRs currently.</div><div><br></div><div><a href="https://metalgeekblog.wordpress.com/2016/08/17/jenkins-creating-multijob-matrix-jobs-in-for-simplifying-committed-and-pr-jobs/" target="_blank">https://metalgeekblog.<wbr>wordpress.com/2016/08/17/<wbr>jenkins-creating-multijob-<wbr>matrix-jobs-in-for-<wbr>simplifying-committed-and-pr-<wbr>jobs/</a><br></div><div><br></div><div>I hope this helps.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="gmail-h5">On Wed, May 31, 2017 at 10:44 AM, Václav Pavlín <span dir="ltr"><<a href="mailto:vasek@redhat.com" target="_blank">vasek@redhat.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5"><div dir="ltr">Hi all,<div><br></div><div>I am very new to Jenkins, so please bear with me:)</div><div><br></div><div>We have this JJB config: <a href="https://github.com/almighty/almighty-jobs/blob/master/devtools-ci-index.yaml" target="_blank">https://github.com/alm<wbr>ighty/almighty-jobs/blob/maste<wbr>r/devtools-ci-index.yaml</a></div><div><br></div><div>Where there is this job-template: <a href="https://github.com/almighty/almighty-jobs/blob/master/devtools-ci-index.yaml#L195" target="_blank">https://github.c<wbr>om/almighty/almighty-jobs/blob<wbr>/master/devtools-ci-index.yaml<wbr>#L195</a></div><div><br></div><div>The script basically copies content of git cloned directory and runs build script. If that run is successful it deploys the resulting docker image to OpenShift.</div><div><br></div><div>We want to deploy images by tag - which corresponds to git commit hash, so it gets templated in by oc process. </div><div><br></div><div>The problem is that there are templates which have more parameters and we have taken care of this with a small script in this repostory: <a href="https://github.com/openshiftio/saas/" target="_blank">https://github.com/<wbr>openshiftio/saas/</a></div><div><br></div><div>So my goal is to use that saas tool to do the deploy instead of plain oc process > oc apply.</div><div><br></div><div>As we have multiple templates which have different scripts, I'd like to avoid code duplication - I don't want to copy&paste the oc process/oc apply or the script calls around in the file.</div><div><br></div><div>So my thinking to solve this was to create some kind of hierarchy - I found something about dependencies and something called multijob where a job would trigger a build phase (build a docker image) and a deploy phase (oc apply). The key part is that if any of the phases fail, whole job fails. Also, deploy phase must not be triggered when build phase fails.</div><div><br></div><div>What would be the correct approach with JJB to solve this? Is this wrong thinking? Am I missing something from the Jenkins point of view?</div><div><br></div><div>I know this would be ideally solved by pipelines, but I don't think that is an option at the moment.</div><div><br></div><div>Looking forward to comments and suggestions,</div><div>Vašek<span class="gmail-m_-7228155881516668444HOEnZb"><font color="#888888"><br clear="all"><div><br></div>-- <br><div class="gmail-m_-7228155881516668444m_-5881357465044512726gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="font-size:12.8px"><div dir="ltr">Red Hat Developer Tools team<br>Brno, Czech Republic<br>Phone: <a href="tel:+420%20739%20666%20824" value="+420739666824" target="_blank">+420 739 666 824</a><br></div></div><div style="font-size:12.8px"><br></div></div></div></div></div>
</font></span></div></div>
<br></div></div>______________________________<wbr>_________________<br>
Ci-users mailing list<br>
<a href="mailto:Ci-users@centos.org" target="_blank">Ci-users@centos.org</a><br>
<a href="https://lists.centos.org/mailman/listinfo/ci-users" rel="noreferrer" target="_blank">https://lists.centos.org/mailm<wbr>an/listinfo/ci-users</a><br>
<br></blockquote></div><span class="gmail-HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="gmail-m_-7228155881516668444gmail_signature"><div dir="ltr">-== @ri ==-</div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="font-size:12.8px"><div dir="ltr">Red Hat Developer Tools team<br>Brno, Czech Republic<br>Phone: +420 739 666 824<br></div></div><div style="font-size:12.8px"><br></div></div></div></div></div>
</div></div>