I am currently doing an analysis whether jenkins could fit for our needs.
Therefore I need to know something about (NOT) reloading configurations:
I know that there is an explicit way to reload a configuration (via WebGUI and CLI).
BUT:
Is there also a way to PREVENT Jenkins from reloading configs?
One requirement is that the CI-System reads in all config-files (general and job-configs) ONCE at the start of the ci-system. And afterwards a modification of the config-files shall take NO effect!
Do you know whether this is already the case (except I press that button under "manage Jenkins" | "reload Configuration from hard disk" [exact options might sound a little different because I only have a German version here])
Would be very thankful for your help,
Lukas
I run a Git repo to control the config.xml files so have experience of the xml files changing while Jenkins is running.
I can confidently state that Jenkins will not reread the config.xml file unless you specifically ask it to via the UI or cli. In fact if the config is changed via the UI any changes that has been done to the config.xml file will be overwritten with the in-memory version.
Related
I have a groovy file that runs at the time of deployment to create predefined admin users for jenkins. I would like to add a logic here that would enable the allowsignup option. By default the option is disabled.
First I tried making changes in the config.xml file hoping that when I'd restart jenkins it would enable the option but that didn't work.
Now I'm suspecting that maybe I need to make changes via a groovy file using the hudson.security.HudsonPrivateSecurityRealm module, but I'm not exactly sure how to go about doing this.
I am also not sure whether this is possible or the option can only be enabled via UI.
I'm looking for something like the Job Config history plugin but to log the changes in the Jenkins server itself (any change under the /manage section or credentials).
I tested the Audit Trail plugin, but it only logs who and when, but nothing about the content of the change.
I'm using the roles based strategy, so there is a reduced group of people able to do changes, but I still need more precise information.
Job Config History Plugin also tracks system configuration. Just click on Job Config History (on the left-side menu) on the main dashboard (outside of any job). When there, you can see all server configuration changes with all features like diffs and raw XML access.
Recently, in our enterprise production setup, it seems someone has tried to setup a new job / test definition by using another (copying) from identical job. However, (s)he seems to have NOT saved (and probably, am guessing here, closed the browser with the session being lost).
But the new job got saved though it was not set to stable or active; we knew about this because changes uploaded to gerrit, started failing in this newly setup partial job (because, these changes were in certain repos that met certain TDD settings).
Question: Jenkins system does not have trace of who setup the system in 'configure versions' option. Is there anyway to know the details of who setup the job / when was that done ?
No, Jenkins does not store that information by default.
If your Jenkins instance happen to be running behind an Apache or Nginx web server, there might be access logs that can help you. To find out when the job was created you could look at when its config.xml file was created/modified.
However, there are a few plugins that can add this functionality so that you won't have this problem again:
JobConfigHistory Plugin – Tracks changes in your job configurations and gives the ability to restore old versions.
Audit Trail Plugin – Keeps a log of who performed particular Jenkins operations, such as configuring jobs.
I work with a Jenkins server in which JobConfigHistory plugin is installed.
This server has been used for a while, and I think many other plugins are installed as well.
On this server, I get multiple config change history recorded when I make a change to job configuration.
I don't want this behavior; I want only single history change for a single configuration change.
I guess some Jenkins server config or some installed plugin is the cause of this problem, but I have no clue what I should do to find it out.
Any idea?
There is a Jenkins issue that has been resolved recently:
[JENKINS-22224] one job configuration change results in three Job Config History entries.
But:
Danny Staple added a comment - 20/Nov/14 5:17 PM
We are seeing a general problem here - some of the plugins appear (parameterizedTrigger, ThrottleConcurrentbuilds, NodeLabel, ExtendedChoice are current suspects) to do this too - we are now having as many as 8 (!!) saves in the config. For some plugins, it seems that when there is no change, they save a no-diff config. Almost as if each is doing their own save in order.
Marc Günther added a comment - 20/Nov/14 5:23 PM
+1
We are not using disk-usage plugin anymore, cause it's so slow, but I still see this behaviour. So it's definitely not restricted to disk-usage plugin alone....
The plugin persists the changes whenever the configurable entity is saved regardless there is any change or not. Note there is a global option for the plugin Do not save duplicate history to save only unique changes.
I asked the following two questions in JIRA Answers, but got no reply so far:
Question 1
Question 2
Basically my question is what's the best way to make changes in a JIRA production environment.
This will be rather general answer, but this is how I do it:
I avoid modifying JIRA production files. When I need it (e.g. mail templates), I keep them under source control along with plugin in 'deploy' directory which mimics JIRA directory structure so it is possible to grap it and deploy it with copy&paste
I frequently use javascript to decorate screens with custom behavior
Schema changes, custom fields and other meta data are all created in code
Keep everything in plugin and leverage plugin versioning system. Plugin should be able to check whether there is everything it needs and when not it should be able to upgrade incrementally.
For JIRA configuration - this is the same, plugin should check whether it has everything it needs, but you can also keep configuration changes in some excel file and have it under source control
My aproach is to have everything possible in source control and modify production files only when absolutely necessary. Do as much in code as possible.