At an earlier job we installed a VC history plugin (I don't know which one) to at least have basic history of configuration changes, but it had several problems:
- It would often get into an unrecoverable state, and we would have to SSH into the box to clean things up to allow it to continue (and in the meantime we would lose all history).
- Trivial automated changes from another plugin would flood the log. Not this plugin's fault, of course, but Jenkins is unusable without lots of plugins, most developed in isolation from others.
Everyone I've talked to about this prefers the GitLab model of telling the server everything relevant to your build at build time. Where Jenkins would need copies of jobs or synchronized configuration updates, GitLab just assumes that each commit has the job configuration it needs.
Comments
we use https://wiki.jenkins.io/display/JENKINS/JobConfigHistory+Plu... to track job config changes. Additionally we require users to checkin the config.xml for each job in VCS- It's easily accessible by appending config.xml to the Job URL eg. http://server/job-name/config.xml
That seems to take care of who changed, what changed, etc.
At an earlier job we installed a VC history plugin (I don't know which one) to at least have basic history of configuration changes, but it had several problems:
- It would often get into an unrecoverable state, and we would have to SSH into the box to clean things up to allow it to continue (and in the meantime we would lose all history).
- Trivial automated changes from another plugin would flood the log. Not this plugin's fault, of course, but Jenkins is unusable without lots of plugins, most developed in isolation from others.
Everyone I've talked to about this prefers the GitLab model of telling the server everything relevant to your build at build time. Where Jenkins would need copies of jobs or synchronized configuration updates, GitLab just assumes that each commit has the job configuration it needs.