Jenkins Configuration as Code (JCasC) drift detector

Project goal: Report differences between a Jenkins active configuration and a given JCasC definition

Skills to study/improve: Java



A well designed Configuration Process only allows updating Jenkins via Configuration as Code. Consequently, it periodically and "blindly" overwrites 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 changes on Production, to allowing a developer to experiment to determine 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 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 which configuration elements would be created or changed if the supplied JCasC file were applied to the specified Jenkins system.

    • Ability to configure the details displayed for sensitive elements (credentials, sensitive configuration, etc)

    • Ability to opt out of updating or displaying these 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 indicating whether the controller’s configuration is equivalent to the supplied JCasC configuration (did the configuration drift?)

Project Difficulty Level

Beginner to Intermediate

Project Size

175 hours

Expected outcomes

New feature

Details to be clarified interactively, together with the mentors, during the Contributor Application drafting phase.

Potential Mentors

Project Links

Organization Links

> Go back to other GSoC 2023 project ideas