search

jenkinsci / configuration-as-code-plugin

Jenkins Configuration as Code Plugin
https://plugins.jenkins.io/configuration-as-code
MIT License
2.69k stars 718 forks source link

Configuration changes made via jenkins GUI is written to CASC_JENKINS_CONFIG/jenkins.yaml file #1426

Open DavidRodHub opened 4 years ago

DavidRodHub commented 4 years ago

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.

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.

peterloron commented 4 years ago

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.

DavidRodHub commented 4 years ago

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

IliaGe commented 3 years ago

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 :(

anushamalledi commented 3 years ago

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 ?

jetersen commented 3 years ago

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.

y0zg commented 2 years ago

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?

jetersen commented 2 years ago

Not likely. See my first comment for details https://github.com/jenkinsci/configuration-as-code-plugin/issues/1426#issuecomment-767729563

y0zg commented 2 years ago

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

y0zg commented 2 years ago

And the problem is that I cannot download current config via CASC for pipelines, it's applicable only for jenkins general settings

y0zg commented 2 years ago

@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?

jetersen commented 2 years ago

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

y0zg commented 2 years ago

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

jetersen commented 2 years ago

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.

y0zg commented 2 years ago

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.