Page MenuHomePhabricator

Jenkins: Figure out a long term solution to maintaining Jenkins configuration
Closed, DeclinedPublic


Since the start, Jenkins has been using the smtp.pmtpa.wmnet DNS entry to send its email. The DNS entry has been removed yesterday and no mails were sent anymore. I have set jenkins to use instead.

Faidon recommended to use the puppet variable $::mail_smarthost , but Jenkins configuration is not maintained by puppet.

We should either:

  • puppetize Jenkins (0% chance it is going to happen)
  • use Puppet to set SMTP relay listening on localhost and point Jenkins to it. The conf will be managed by puppet and the entry will be stable in Jenkins config
  • find out a stable DNS entry to use instead of

Version: wmf-deployment
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:35 AM
bzimport set Reference to bz67027.
bzimport added a subscriber: Unknown Object (MLST).

To clarify, Puppetizing Jenkins in general is definitely not a 0% chance thing. That's very much a 100% thing. For the most part I think it is puppetized already.

The story here is specifically about it's configuration, which Jenkins internally stores as an XML file on disk on

Antoine and I both would not support that moving into operations/puppet.git (e.g. as file ensured by puppet, or an erb file expanding to xml with placeholders for $::mail_smarthost etc.). Because that would effectively make it very hard for us to do your job as these configuration values change quite frequently.

It can be compared to mediawiki-config. You wouldn't want every change there to go through operations/puppet. That's why we made a hybrid solution there with operations/mediawiki-config so that it is versioned, tracked and reviewed, but with deployers for wmf-mediawiki having write access to it as well. When ops makes changes that affect mediawiki, they update the config. And day-to-day the config is handled by deployers.

I'd like to propose a similar approach for Jenkins. We'd have operations/jenkins-config containing the XML files (or something that compiles to XML). And clone the repo on gallium (like for mediawiki-config on tin and zuul-config on gallium alreadsy).

One can probably puppetize a chunk of it based on But I am opposed to have the Jenkins configuration maintained in puppet because we have no rights on it (i.e. no +2 / merge).

Faidon proposal was to use puppet to have the Jenkins config to rely on $::mail_smarthost . Instead, we can probably have a local smart host relay reachable on that will be configured to relay mail to $::mail_smarthost. That would fix that specific issue.

  1. Put the xml file in operations/puppet as template with placeholders for dynamic/private data and ensured in the right location on gallium.
  1. Use Puppet File::notify to have Jenkins reread/reload config from disk (it has an option for that in the web ui, I hope it supports doing this from command line as well, otherwise we can do a graceful restart).

@zeljkofilipin related to puppetization of Jenkins.

Also look at how OpenStack is handling their Jenkins config ( T95049: Figure out how Jenkins conf is maintained by OpenStack ).

hashar edited subscribers, added: thcipriani; removed: wikibugs-l-list.

With the recent gallium / CI outage, lack of Jenkins config management has been a threat. Moving the task to phase out gallium project.

Moving this out of the phase out gallium project. Having part of Jenkins unpuppetized is definitely an issue but should not hold from migrating it to another machine. We can still rsync the current config.

We definitely need to address that Technical-Debt though.

Been playing it a bit with this today. On jenkintest.integration.eqiad.wmflabs I have installed a basic jenkins. It generates a few files under /var/lib/jenkins, interesting candidates are:

When connecting to the web interface and doing a noop change in the configuration the following dummy files are generated:


They are the default configuration files of:

  • Jenkins itself config.xml (see below)
  • built-in plugins (can be found as /plugins/*.jpi) and global "tasks" such as shell/maven etc.
  • some magic secrets/hudson.util.Secret
<?xml version='1.0' encoding='UTF-8'?>
  <authorizationStrategy class="$Unsecured"/>
  <securityRealm class="$None"/>
  <projectNamingStrategy class="jenkins.model.ProjectNamingStrategy$DefaultProjectNamingStrategy"/>
  <viewsTabBar class="hudson.views.DefaultViewsTabBar"/>
  <myViewsTabBar class="hudson.views.DefaultMyViewsTabBar"/>
      <owner class="hudson" reference="../../.."/>
      <properties class="hudson.model.View$PropertyList"/>

We can probably gives a shoot at the config.xml. When we start inserting credentials in there, they will need to be encrypted using the secret.key though so that might not be so trivial. Maybe puppet can invoke a groovy script to do so.

Mentioned in SAL (#wikimedia-releng) [2017-03-01T17:11:30Z] <hashar> cleaned out Jenkins security matrix to drop users that are no more used/inexistent -- T69027

I filled that task since Jenkins hardcoded the smtp server which caused some issues whenever the entry changed. At the time we were not allowed to have a local relay, but eventually that changed.

Since Sep. 2018, the CI Jenkins sends email to localhost T203607

There is not much interest in tracking Jenkins configuration changes for now. We are even considering dropping it entirely. So I am just declining this for now.