Please find hereafter another GSoC Project proposal. Questions, comments, suggestions are welcome.
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)
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?)
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).
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
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.