This charm provides the ability to manage configuration of Juju-deployed
CI infrastructure, including the Jenkins, Zuul and Gerrit services. It
is intended to manage the three of them together to create a CI
review/build/test pipeline, but can be used to a single service or subset of
services if the entire pipeline is not required.
The charm functions as a subordinate charm with separate interfaces capable of
relating to the three principle services (Jenkins, Zuul and Gerrit). The
charm contains minimal Juju charm configuration data and instead makes use
of a specified bzr repository to allow users to manage configuration out of
band from the Juju environment. Doing so allows users other than those
with direct access to the Juju environment to push configuration changes
to the principle services.
The deployment of Jenkins, Zuul and Gerrit services are beyond the scope
of this document. Assuming they have been deployed and properly related,
this subordinate may be deployed with proper configuration settings and
related to each. It may be related to each principle service by via
its own relation interface: gerrit-configurator, jenkins-configurator
and zuul-configurator. Relation hooks for each interface know how to
configure the principle service based on data contained in the configured
juju deploy ci-configurator juju add-relation ci-configurator zuul juju add-relation ci-configurator gerrit juju add-relation ci-configurator jenkins juju add-relation ci-configurator jenkins-slave
Repository management, offline and online
This charm is intended to be deployed in environments that have outbound
internet access. Internet access is used for branching the configured
bzr repository and installing the jenkins-job-builder project from pypi.
In environments where internet access is restricted, both of these may
be "bundled" with the charm prior to deploying, such that they will be
shipped to machine units in and installed from the charm itself. To
do so, you must branch the charm locally and run two Makefile targets:
$ bzr branch lp:~canonical-ci/charms/precise/ci-configurator/trunk \ ci-configurator $ cd ci-configurator # Pulls in jenkins-job-builder and required dependencies $ make sourcedeps # Branches specified repository and bundles it in charm. This branch # is what would be configured as 'config-repo' configuration setting # in an online environment. $ CONFIG_BZR_REPO=lp:~canonical-ci/canonical-ci/<project>-ci-config \ make configrepo
You may now deploy from the local repository and resources will be available to
the charm locally instead of attempting to fetch from the net.
In either case, the repository ends up cloned to:
The bzr repository that is branched and used by the charm should follow a
specified layout, as the charm expects certain files and scripts to be in
specific locations. At the top level, a subdirectory should exist for
each service the repository is managing. If one is missing and a relation
is added, configuration of that service is skipped:
$ tree -L 1. |--control.yml +-- gerrit +-- jenkins +-- zuul
The control.yml file is currently used to specify additional package
and plugin dependencies that are required to run the jenkins jobs configured
in the repository (see jenkins section below), but the scope of this file may
expand in the future to also specify dependencies for Zuul and Gerrit.
The layout of the per-service subdirectories and the integration with the charm
is described below:
The ci-configurator charm knows how to manage gerrit hooks, permissions,
projects and the gerrit theme. Each bit is managed in its own subdirectory:
gerrit/ |-- hooks | |-- change-merged +-- permissions | |-- All-Projects | |-- project.config +-- projects | |-- projects.yml +-- theme +-- | files | |-- GerritSite.css | |-- GerritSiteHeader.html +-- static |-- canonical_header_b |-- canonical_logo
Files in hooks/ get installed into the local gerrit services hooks directory
(/home/gerrit2/review_site/hooks/ by default)
The projects.yml file in projects/ subdirectory contains the Gerrit projects
configuration. The permissions/All-Projects/project.config contains the
permissions settings for all configured Projects. When updating, these files
get committed and pushed to the local, internal gerrit config git repository.
The files hosted in the theme/ directory are used to customize the gerrit
theme and get installed to /home/gerrit2/review_site/etc/ and
/home/gerrit2/review_site/static/ by default.
If the gerrit/ subdirectory is missing in repository, updating gerrit is
skipped. If any subdirectory of gerrit/ is missing in repository,
configuration of that gerrit component is skipped.
required_jenkins_packages: - git - python-pip - python-mock required_jenkins_plugins: - git-client - git
The zuul section of the repository currently is used only for installing
the zuul layout.yml:
zuul/ -- layout.yml
When updating zuul, this file is installed to /etc/zuul/layout.yaml and the
The charm makes use of the jenkins-job-builder tool to define jenkins
jobs and update jenkins server configuration:
The repository should contain jenkins-job-builder compatable yaml job
templates in jenkins/jobs/ subdirectory. It should also contain a
executable script named 'update' which is used by the charm for injecting
any relevant environment data into the yaml templates where required:
jenkins/ |-- jobs/ |---- job_templates.yml |---- macros.yml |---- projects.yml |---- update |-- security/ |---- config.xml
Its currently up to the repository's update script to decide how it wants
to inject data into the jenkins-job-builder configs. Prior to calling this
update script, the charm's configuration and relation data to principle
jenkins service is dumped to a json file at:
One example use case:
The jenkins_job configs setup jenkins jobs that use the gearman plugin
to connect to a remote zuul service (expressed by a
jenkins <-> zuul relation). The principle jenkins service exports the zuul
address via its relation to the subordinate ci-configurator service. The
ci-configurator charm dumps this address and other charm context to
the json file and calls the repo's update hook. The update hook then
injects the zuul address into the various job configurations.
After the update hook is called, the 'jenkins-jobs' script is called to
actually create or update the jobs in the running jenkins cluster.
It may also be required to install additional packages or Jenkins plugins
in order to run the jobs defined in the repository. These may be defined
in the control.yml file shipped in the reposotiry. This packages and
plugins will be installed on the jenkins principle upon every hook run:
required_jenkins_packages: - git - python-pip - python-mock required_jenkins_plugins: - ssh-agent - gearman-plugin - git-client - git
Updating configuration in any of the services is a matter of updating
the config repository and triggering a charm event that will pull in
the changes and run the various update bits. The charm has the ability
to run from a specified revision of the repository, or to run from trunk.
Triggering an update depends on whether the charm was deployed in offline
mode or online mode and whether it is set to run from a revision or trunk.
If set to run from trunk, the charm may optionally install a cronjob to
pull in new revisions on a specified interval and update configuation
in services. Optionally, if you do not wish to have this automated you
may trigger updates using via the update-trigger config setting:
juju set ci-configurator update-trigger=$(uuid)
If set to run from a specified revision, it is just a matter of setting
the revision in the charm config. The charm will pull the revision and run
the various update bits.
(NOTE: cron installation still TODO)
New revisions to the repository need to be rebundled locally into the charm,
the local charms revision bumped and the charm upgrade. If the repository
bundled with the charm already contains an updated repository, and you wish
to run from a specified revision number, this may be set normally via
- (string) Revision control repository url containing collection of yaml files containing jenkins-job-builder configs. This may also be packaged locally prior to deploying by running 'make configrepo' target of the Makefile to pull from a specified repository. Again, any bundled assets will override any setting set here. The contents of this repository (or anything packaged with the charm) will end up installed in/etc/jenkins-job-builder/job-configs/ on the service unit. Launchpad git branches should use the full URL; the 'lp:' prefix will not be expanded.
- (string) The RCS system to use to fetch the config-repo. Supported options: bzr git
- (string) If config-repo specified, which revision to use. Defaults to "trunk", and is updated on during every config-changed hook. ("trunk" will be interpreted as "master" if config-repo-rcs is git)
- (string) Comma-separated list of hosts that should have strict host checking disabled in the user that is configuring the charm; this is to allow git cloning of jenkins-job-builder configuration over SSH without interactivity.
- (boolean) If set to true, packages listed in control.yml will be forced to install with the --force-confnew and --force-confdef apt options
- (string) Installation source for jenkins-job-bulider. Supported options: distro (only supported on Ubuntu 13.10 and later) git://github.com/openstack-infra/jenkins-job-builder.git or similar Alternatively, you may run the 'make sourcedeps' target of the Makefile to package required assets into the charm prior to deploying, for environments where network access is restricted. Any bundled package will override any value set here.
- (string) Credentials for login into Launchpad to retrieve team membership.
- (string) Launchpad login name of user branching bzr repo (required for private branches).
- (string) Cron-formatted schedule for launchpad sync
- */15 * * * *
- (boolean) If configured to run from trunk of a remote repository, you may optionally have the charm install a cronjob that will periodically pull trunk and update Jenkins.
- (string) SSH private key for associated LP user.
- (string) SSH public key for associated LP user.
- (string) If schedule-updates is True, update-frequency sets the schedule on which the cronjob updates the branch and pushes changes to Jenkins.
- (string) Used to force config-changed hook runs.