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

@Jmm i would like to work on this project what thinks I need to do regarding project if you guide me this would be very beneficial to me

1 Like

Ooops ! This message slipped under the radar screens. I apologize for this.

In order to get to speed for an efficient mentoring, the first and probably most important thing to do is to become very proficient on JCasC (practical and hands-on experience). Another need-to-know is the use of the CLI (various flavour). The third preparation work is to work on your own on several architectural ideas to solve the drift detection as well as project plans and scopes ideas. The contributors will work on their own interpretation of the problem, but the more we thought about this beforehand the better we can guide them (pointing to forgotten topics or questions, hint for exploration paths, etc).

@Jmm I think @pushker001 wants to contribute as a contributor rather than a mentor.

Mmmh… You might be right. I might mix the handle with somebody else… E-INFO-OVERLOAD…

@pushker001 Could you clarify what kind of guidance you would like?

/- Jmm

@pushker001 For any contributer-related questions, please head to our Gitter channel at jenkinsci/gsoc-sig - Gitter. There we will be better to answer your queries better.

As Jim tells us to explore the Jenkins I watched the improve the plugin tutorial now what next I was trying to solve the random issue but faced difficulty in solving it can you guide me regarding this

@pushker001 What issue has you been working on? Could you share a link with us?

@pushker001 So I would suggest to do some investigation further, such as going back to the source of the original problematic stack trace at configuration-as-code-plugin/ at aa06e58d11e3b5fbe2baea92523d53bdd5b1f0d1 · jenkinsci/configuration-as-code-plugin · GitHub. There is an example of this stack trace at, which has been given at jenkinsci/configuration-as-code-plugin - Gitter. Then, do some research about how other more modern plugins would handle this type of error and try to imitate it.

how do check how other modern plugins are handling this issue

I explore the plugin mask password plugin as you told me and explore the source code as you have given me the original problematic stack trace at configuration as a code plugin I search the
keyword related to it and found this

line no 56

1 Like

Hi @pushker001 Good start! I think a good example of a more modern way to handle the ConfiguratorException is the Git plugin: git-plugin/ at 5edc26da3bd4962bdb8599ef1cbc40d335cd1129 · jenkinsci/git-plugin · GitHub. If you compare this to the source code we will need to update you can see that maybe we don’t really need to show all the unknownKeys. One way I would suggest you approach the problem is to try and reproduce the error yourself, then you can play with ways to generate a more modern stack trace like the one shown in Git.

I also tried to work on the same issue and came up with a PR Fixes #1846 by displaying a user-friendly error message instead of a stack trace on boot error by lakshmishreea122003 · Pull Request #2199 · jenkinsci/configuration-as-code-plugin · GitHub but some checks were unsuccessful. Please may I know if there is a way to modify what I have done to pass all checks or else I shall do some research about how other more modern plugins would handle this type of error and try to imitate it as advised by @krisstern .

1 Like

Hey @Jmm @krisstern I’m interested in this project & also would like to contribute to it

1 Like

Hi @i-am-yuvi Thanks for your interest in the project! You may start by browsing through the issues tracker for the relevant repo at Issues · jenkinsci/configuration-as-code-plugin · GitHub to see if you can submit some pull requests for at least one or two of these issues before official GSoC applicaiton form opens next month on March 20th. If you have any further questions you can pose them on our GSoC Gitter channel at, where most of our conversations regarding GSoC are hosted.

Please note that this project idea is being withdrawn. If you have prepared a proposal for this project idea, please consider preparing a new proposal for one of the remaining project ideas still on offer. For details please see IMPORTANT NOTICE: Project Ideas withdrawal.