Configuration changes made via jenkins GUI is written to CASC_JENKINS_CONFIG/jenkins.yaml file
DavidRodHub opened this issue · 14 comments
Jenkins 2.235.1
Configuration as Code Plugin 1.41
Ubuntu 18.04
Feature Request:
When modifying the jenkins configuration or adding a job through the GUI, the JENKINS_HOME/config.xml is correctly updated but the JENKINS_HOME/casc_configs/jenkins.yaml file, used to configure jenkins, is NOT updated with the change. So when jenkins is restarted, the configuration-as-code plugin uses the CASC/jenkins.yaml file to configure jenkins which DOES NOT have the change.
Note that after the change is made through the GUI, then viewing the configuration-as-code/viewExport, the change is reflected in the viewExport. Could the JENKINS_HOME/casc_configs/jenkins.yaml /jenkins.yaml file be updated at that time when changes are made through the GUI. Note that jenkins updates JENKINS_HOME/config.xml file when changes are made through the GUI.
- Manage Jenkins
- Configuration as Code
- view Configuration (viewExport)
The configuration-as-code plugin is great for initially configuring a new jenkins instance. But after the jenkins instance is created, any additional changes require the jenkins.ymal file to be manually updated, then jenkins needs to be restarted for the change to take affect.
For us after the jenkins instance is created and up and running. We typically delete and add many jobs as new versions of our components are being developed. It's a lot easier to delete and add jobs through the GUI which does not require jenkins to be restarted.
Jobs can be easily managed (and version controlled, etc) with JobDSL, and if you DONT make config changes through the UI, only though the config files, you also get the benefit of version control, etc. You can trigger the Jenkins instance to reload the JCasC configs without restarting, and the JobDSL doesn't require a restart, either.
Hi peterloron, not familiar with JobDSL plugin. I'll look into it to see how to manage changes to jenkins and version control the jenkins.yml file
Hey,
I'm joining the initial request/question ...
Why changes made within the GUI are not saved to the jcasc Configmap (jenkins-jenkins-jcasc-config)?
If people change configuration and restart the Jenkins POD, the config is overwritten by the jcasc without the last changes :(
Any update on this issue ? While providing service to customer, updating JcasC and deploying is taking longer than just updating in straight forward GUI. But unfortunately, updating GUI and then Jcasc in source code is creating duplication of work. Any suggestions around this ?
The export is not reliable and does not understand secrets, the exported file will in most cases not match what you have version controlled also any comments would be removed. Again the idea is to support version controlled configuration, which changing things in the GUI is not.
The suggestion is to have test instance in docker make the change than export and than add the needed bits to your version control system.
You could look into: https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/docs/features/configurationReload.md also the config can be a URL so there are some options.
Is configuration reloading the only option https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/docs/features/configurationReload.md ? Would this feature be delivered, any plans?
Not likely.
See my first comment for details
#1426 (comment)
This option doesn't work for me so far, if I set some specific settings in job (jobs checkbox settings) and reload jenkins, those checkbox settings would be flushed. Any idea how to make them persistent? I know that custom settings should be added to jenkins.yaml but in this particular scenario I don't know exactly what should I add having only this example https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/demos/jobs/pipeline.yaml
And the problem is that I cannot download current config via CASC for pipelines, it's applicable only for jenkins general settings
@jetersen
It's possible to create jenkins jobs via DSL using this reference https://jenkinsci.github.io/job-dsl-plugin/#path/pipelineJob-authorization
but I see it's still a problem to keep the last state of jobs which use shared library and parameters after jenkins restart
In order to have "Build with parameters" option or use shared library, I need to start the job once with "Build".
But whenever Jenkins with CASC plugin restarts, I need again to trigger job in order to have required "Build with parameters"
Any thoughts?
Have you tried a seed job that checks for whether your jobs exist or not?
or perhaps you should reduce your complexity in your Jenkins pipeline?
https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/docs/seed-jobs.md
Thanks, @jetersen !
Yes, I use such example https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/demos/jobs/pipeline.yaml for jobs with CASC and it works well during initial jenkins start. I have all the jobs created.
The problem comes after jenkins restart, if there are any parameters in the pipeline itself or shared library is used, then after jenkins restart I'll need to run all the jobs again in order to make jobs workable
Update: it seems more job settings can be added with jobdsl https://jenkinsci.github.io/job-dsl-plugin/#path/job-parameters, but I still need to test shared library
Parameters belong to the build system or scripts that Jenkins is triggering. Your build should be deterministic and Jenkins should only be your trigger but that is just my honest opinion.
I am unsure what your trying to achieve but it seems like your attempting to solve something that can be solved in the repository that your triggering on.
There are some references regarding shared library behaviour. CASC plugin usage might require to run such jobs once again after each jenkins restart, but I have to test it
https://www.jenkins.io/doc/book/pipeline/shared-libraries/
...those jobs must run successfully once before the shared library documentation will be generated.
https://hrmpw.github.io/jenkins.io/doc/book/pipeline/shared-libraries/
A variable defined in a shared library will only show up in Global Variables Reference (under Pipeline Syntax) after Jenkins loads and uses that library as part of a successful Pipeline run.