A while back we discussed use of JJB, and I did some proof-of-concept
work on it [1]. After considerable effort (and some good detective
work from Dominic!) I'm happy to say that JJB is now live on ci.theforeman.org!
Of course, not every job has been moved to JJB yet. The jobs currently
configured this way are:
deploy_deb
deploy_web
packaging_build_deb_coreproject
release_nightly_build_deb
release_nightly_push_deb
release_nightly_test_deb
systest_foreman
job test_proxy_develop
You can find the YAML code for these jobs at [2]. Note that this
constitutes the entire (deb) pipeline for the proxy - the rpm half
will probably be the next target.
There's a lot more work to do, of course. We need to convert all the
remaining jobs, and DRY up the code (for example, use of job templates
will greatly simplify the repetetive jobs such as the plugin ones).
PRs to [2] are most welcome if you wish to join in.
In the meantime, for those of us who are making changes to jobs in the
Jenkins UI, please be aware of JJB. If you change a JJB-managed job,
it will be reverted within 24 hours (there's a scheduled exec in the
puppet code), so you'll be better off making a PR for the changes you
need (which will be deployed within 30min via a notified exec).
···
----- Original Message -----
> Hi all,
>
> A while back we discussed use of JJB, and I did some proof-of-concept
> work on it [1]. After considerable effort (and some good detective
> work from Dominic!) I'm happy to say that JJB is now live on
> ci.theforeman.org!
>
> Of course, not every job has been moved to JJB yet. The jobs currently
> configured this way are:
>
> * deploy_deb
> * deploy_web
> * packaging_build_deb_coreproject
> * release_nightly_build_deb
> * release_nightly_push_deb
> * release_nightly_test_deb
> * systest_foreman
> * job test_proxy_develop
>
> You can find the YAML code for these jobs at [2]. Note that this
> constitutes the entire (deb) pipeline for the proxy - the rpm half
> will probably be the next target.
>
> There's a lot more work to do, of course. We need to convert all the
> remaining jobs, and DRY up the code (for example, use of job templates
> will greatly simplify the repetetive jobs such as the plugin ones).
> PRs to [2] are most welcome if you wish to join in.
>
> In the meantime, for those of us who are making changes to jobs in the
> Jenkins UI, please be aware of JJB. If you change a JJB-managed job,
> it will be reverted within 24 hours (there's a scheduled exec in the
> puppet code), so you'll be better off making a PR for the changes you
> need (which will be deployed within 30min via a notified exec).
>
> Cheers,
> Greg
>
> [1] https://groups.google.com/d/topic/foreman-dev/V2TjPFuOpAA/discussion
> [2]
> https://github.com/theforeman/foreman-infra/tree/master/puppet/modules/jenkins_job_builder/files/config
>
> --
> You received this message because you are subscribed to the Google Groups
> "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
What is the workflow to convert an existing job to a JJB job?
What would you recommend converting first? Jobs that are stand alone?
How did you test a job when converting?
Thanks,
Eric
···
On Fri, Mar 13, 2015 at 10:13 AM, Ivan Necas wrote:
Awesome news!
– Ivan
----- Original Message -----
Hi all,
A while back we discussed use of JJB, and I did some proof-of-concept
work on it [1]. After considerable effort (and some good detective
work from Dominic!) I’m happy to say that JJB is now live on ci.theforeman.org!
Of course, not every job has been moved to JJB yet. The jobs currently
configured this way are:
deploy_deb
deploy_web
packaging_build_deb_coreproject
release_nightly_build_deb
release_nightly_push_deb
release_nightly_test_deb
systest_foreman
job test_proxy_develop
You can find the YAML code for these jobs at [2]. Note that this
constitutes the entire (deb) pipeline for the proxy - the rpm half
will probably be the next target.
There’s a lot more work to do, of course. We need to convert all the
remaining jobs, and DRY up the code (for example, use of job templates
will greatly simplify the repetetive jobs such as the plugin ones).
PRs to [2] are most welcome if you wish to join in.
In the meantime, for those of us who are making changes to jobs in the
Jenkins UI, please be aware of JJB. If you change a JJB-managed job,
it will be reverted within 24 hours (there’s a scheduled exec in the
puppet code), so you’ll be better off making a PR for the changes you
need (which will be deployed within 30min via a notified exec).
> Couple of questions:
>
> 1) What is the workflow to convert an existing job to a JJB job?
I'll start by assuming you've played around with JJB a little, as to
explain all of it is a big task. Then pick a job, inspect it's config,
and start to write down the YAML. If you look through the jobs we've
done, we already have a good selection of triggers, builders, and
publishers coded up, so hopefully it'll mostly be copy-paste.
> 2) What would you recommend converting first? Jobs that are stand alone?
Pipelines are easy enough to do. Pick something with a small amount of
config rather than something that has to exist independantly.
> 3) How did you test a job when converting?
Ah, the big question. Because I was building a testbed for JJB, I
actually have a VM with a complete Jenkins setup on it, built using
the same infra puppet modules as production.
That's probably overkill though. I'd suggest grabbing the JJB manifest
[1] and applying it to a clean Centos VM. That should set up JJB for
you.
Once you have JJB and some YAML, you can get it to generate XML using
"jenkins-jobs test /path/to/configdir jobname" as per the exec in the
module. Once you have the XML from JJB, you can get the XML for the
current job from the Jenkins API (I think it's GET
/jobs/:jobname/config.xml) and you can diff them. The diffing is a
pain (JJB puts some of the element in a different order, XML–) but we
don't have a better answer yet.
In short:
Build test VM
Apply JJB module
Write YAML
Run JJB
Compare XML
PR to infra
Changes to existing jobs should be much faster to write/review once we
have more confidence in JJB, but for now, it's a bit tedious.
Suggestions to improve the flow are welcome, ofc.
After writing my first conversion and having it deployed (at least, from
what Dominic told me, it should be deployed by now), should I be able to
click on configure and see, for example, the shell script updated with any
changes that were in the YAML? I ask, because I am not seeing that
currently on the deploy_katello_site job.
Eric
···
On Fri, Mar 13, 2015 at 9:01 PM, Greg Sutcliffe wrote:
What is the workflow to convert an existing job to a JJB job?
I’ll start by assuming you’ve played around with JJB a little, as to
explain all of it is a big task. Then pick a job, inspect it’s config,
and start to write down the YAML. If you look through the jobs we’ve
done, we already have a good selection of triggers, builders, and
publishers coded up, so hopefully it’ll mostly be copy-paste.
What would you recommend converting first? Jobs that are stand alone?
Pipelines are easy enough to do. Pick something with a small amount of
config rather than something that has to exist independantly.
How did you test a job when converting?
Ah, the big question. Because I was building a testbed for JJB, I
actually have a VM with a complete Jenkins setup on it, built using
the same infra puppet modules as production.
That’s probably overkill though. I’d suggest grabbing the JJB manifest
[1] and applying it to a clean Centos VM. That should set up JJB for
you.
Once you have JJB and some YAML, you can get it to generate XML using
"jenkins-jobs test /path/to/configdir jobname" as per the exec in the
module. Once you have the XML from JJB, you can get the XML for the
current job from the Jenkins API (I think it’s GET
/jobs/:jobname/config.xml) and you can diff them. The diffing is a
pain (JJB puts some of the element in a different order, XML–) but we
don’t have a better answer yet.
In short:
Build test VM
Apply JJB module
Write YAML
Run JJB
Compare XML
PR to infra
Changes to existing jobs should be much faster to write/review once we
have more confidence in JJB, but for now, it’s a bit tedious.
Suggestions to improve the flow are welcome, ofc.
You are correct, but JJB seems to have hit an error with your syntax -
it doesn't seem to like the bare slashes in your YAML. I've opened a
PR at [1] to fix it
···
On 27 March 2015 at 19:23, Eric D Helms wrote:
> After writing my first conversion and having it deployed (at least, from
> what Dominic told me, it should be deployed by now), should I be able to
> click on configure and see, for example, the shell script updated with any
> changes that were in the YAML? I ask, because I am not seeing that currently
> on the deploy_katello_site job.
