GSoC 2022 Project proposal: Jenkins Configuration as Code (JCasC) drift detector


Please find hereafter another GSoC Project proposal. Questions, comments, suggestions are welcome.

/- Jmm

Goal: Report differences between a Jenkins active configuration and a given JCasC definition.

A well designed Configuration Process will only allow updating Jenkins via Configuration as Code. It will thus periodically and “blindly” overwrite the controller to make sure that the configuration code is equivalent to the running one. This is the recommended practice (best if the interval is kept very short).

But experience shows that compromises need to be made. These exceptions range from interactively validating touchy configuration change on Production, to allowing a developer to experiment the best parameters for a feature, or to an emergency interactive configuration change.

This is typically the case when trying to reach the ideal Configuration Process maturity level.

Another use case is to be able to compare the configuration of two Jenkins controllers (ex: Test vs. Production)

Project proposal:

This project intents to create the tooling, similar to the terraform plan command, to:

  • Show what configuration elements would be created or changed if the supplied JCasC file was applied to the given Jenkins system.
    • Ability to configure the details displayed for sensitive elements (credentials, sensitive configuration, etc)
    • Ability to opt out above mentioned sensitive elements. These elements may be absent or encrypted in the supplied JCasC file.
  • Generate a JCasC yaml with only the detected delta.
  • Give a boolean result whether the controller’s configuration is equivalent to the supplied JCasC configuration (did the configuration drift?)
1 Like