search

juju-solutions / layer-cwr

Layer for building the Juju Jenkins CI env
Other
2 stars 5 forks source link

Decouple jobs from the charm code #89

Open mbruzek opened 7 years ago

mbruzek commented 7 years ago

The layer-cwr currently has the jenkins jobs in the charm code.

I don't expect the charm code to change very frequently but I do expect the Jenkins jobs to be updated fairly frequently. Any fixes for these Jenkins jobs may require updating code in the layer-cwr, building the charm, and updating the bundle. This process can take a while.

In an effort to iterate faster, I propose making the Jenkins jobs a configurable repository with branch support so we can get the Jenkins jobs from github or a resource. Kevin pointed out the PR for backup and restore here: https://github.com/juju-solutions/jenkins-charm/pull/1/files

In addition to decoupling the Jenkins jobs from the charm code I would propose also changing the Jenkins jobs to use Source code management option. Using this option makes Jenkins clone the repo on every build and our Jenkins jobs just call scripts in that repo (so no logic in the Jenkins job, they just call scripts). This decoupling allows us to iterate in the repo and the next time the job runs it has the latest code. No charm or bundle updates needed, and no backup and restore either.

jenkins_source_code_mgmt

This is just best practices we learned from doing a very similar Jenkins CI pipeline and I think could really improve the CWR-CI system. If you have any questions please feel free to contact me and we can discuss.

johnsca commented 7 years ago

This is partially addressed by #92 though there is more to be done there, as mentioned in the description of that. There is also the difference in that, in our case, the SCM repo points to the charm or bundle under test; however, I would like to move toward having the underlying tooling handle all of the SCM access by way of handling overrides in a more generalized way. Among other things, this should lead to our jobs being entirely parameterizable, rather than having a specific job per charm, bundle, repo, etc, which would open us up to being able to use SCM for the job logic, as you suggest.

mbruzek commented 7 years ago

@johnsca I took a look at #92 and I am not sure that addressed what I am trying to get at with this bug. I want to be able to make changes to the Jenkins jobs without releasing a new charm (unless of course there is some operations for jenkins itself that changed). The way I suggested is to change the jobs to pull from git on each build that way you can rev the jenkins jobs outside of the charms.