cd_jenkins | Release Notes


Jenkins is a very powerful Contineous Integration server, allowing automated testing, delivery and deployment for software projects, supported by an ever-growing community providing an almost endless number of plugins.

cd_jenkins is designed to deploy a very specific, basic Jenkins configuration based on pipelines to make use of Jenkinsfiles (located in the software repository) for all Jenkins tasks, so access requirements to Jenkins via GUI or the REST API should be rather limited.

The general idea is to deploy Jenkins from scratch with a variety of default settings within a few minutes, similarly to deploying templates. If something goes wrong on Jenkins (i.e. when updating plugins or playing with settings, as it happpens often enough in development centers), simply redeploy and be back to where you started off successfully, i.e. ready to work.

Since Jenkins is actively managing most of its configuration files by rewriting their content with data from memory, full management through Puppet is not really possible, so deploying a fully working Jenkins master with specific settings including ready-to-go pipeline jobs and views is the objective.

The Module is geared towards using Gitlab or Github for source control, although not mandatory.


**__!!! Attention: Never use this puppet module on systems which have been previously configured manually. It is impossible to predict how and what would have been configured, hence previuos configurations outside the scope of this module may be overwritten! Automated configurations require a test environment to verify that the module suits the purpose intended by the user, as well as tune the parameters, before deploying into live production!!! __**

git Repo



  • install required packages and dependencies for Jenkins
  • install plugins via jpi
  • install certbot (optionally for automated TLS certificates)
  • install Apache httpd web server (optionally, for front-end proxying)
  • install various testing tools (optional)


  • manage initial user settings
  • manage initial configuration files through templates
  • manage credentials externally (optional)
  • manage Apache for front-end proxying through http or https (optional)
  • manage automated TLS certificates for https (optional)
  • plugins

Seed Job (optional)

  • create and configure jobs automatically from a specified Gitlab / Github url via build-job-dsl based on reporitory tags.
    • Job types:
  • create views for the various job types based on regex patterns: Pipeline via Jenkinsfile

Repo Structure

Repostructure has moved to in repo.


All dependencies must be included in the catalogue.


native Puppet deployment

via site.pp or nodes.pp

node '' {
  include cd_puppetdb

through Foreman:

In order to apply parameters through Foreman, cd_jenkins::params must be added to the host or hostgroup in question.

See more details about class deployment on


The following parameters are editable via params.pp or through ENC (recommended). Values changed will take immediate effect at next puppet run. Services will be restarted where neccessary.

Mandatory Parameters

The following parameters must be set to suit your environment:

  • $js_master_node : The FQDN for the jenkins master server. If matched, the server configuration will be applied. Defaults to jenkins_master.${::domain}.



All files and directories are configured with correct selinux context. If selinux is disabled, these contexts are ignored.

Known Problems

  • Content Enforcment: Configuration files are deployed only once, and the file system permissions, selinux etc. are constantly enforced. However the content itself cannot be enforced, as Jenkins tends to write to its files based on memory content, so enforcing content would cause an ongoing conflict and the Jenkins service constantly restarting.
  • Authentication: It is assumed that external authentication mechnisms, like Active Directory or LDAP, will be used, if multiple users have to have access to Jenkins. However, since the idea of this module is to utilize Jenkinsfiles actually located in the software repository, user write access to a production Jenkins should be very limited, if not disabled at all. The Jenkinsfile should be developed in a lab / development instance, where user access can be granted on a very relaxed level.


  • OS: CentOS 7


  • Puppet Lint
    • excluded tests:
    • --no-class_inherits_from_params_class-check:relavant only to non-supported outdated puppet versions
    • --no-variable_scope-check: not applicable as we are inheriting parameters from params class. the lint check does not distinguish between facts and inherited parameters.
    • --no-80chars-check: it is not always possible to stay within 80 characters, although typically only occurring on the parameter vault params.pp.
    • --no-arrow_alignment-check: this check leads to actually not having am easily readable arrow alignment, as this checks per block, not per class.
    • --no-autoloader_layout-check: Jenkins running puppet-lint falsely reports auto-loader errors, while running this manually does not report any errors. am investigating.
  • Puppet Parser
  • ERB Template Parser *

Contact Us

contact Us


ConfDroid as entity is entirely independent from Puppet. We provide custom configuration modules, written for specific purposes and specific environments. The modules are tested and supported only as documented, and require testing in designated environments (i.e. lab or development environments) for parameter tuning etc. before deploying into production environments.

Leave a Reply