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.
Related
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 am using Folder plugin and AD groups to control access to folder. This morning a team can't access their project anymore and later I found the AD group assignment in Assign Roles has been changed to wrong groups. Is there a way to find out which id did it? We only have a few admin ids.
Jenkins does not appear to keep an audit trail by default, as stated in this post on cloudbees.com, the folks that develop Jenkins.
The relevant lines:
Many Jenkins users look for a recommend a strategy for keeping an audit trail. This article is supposed to be a gap filler until more comprehensive compliance capabilities in JE/JOC are developed.
There are two open source plugins that enable you to track “WHO did WHAT?” in Jenkins:
...
The first plugin listed is Audit Trail Plugin which looks to provide exactly what you are seeking.
The description from the plugins page:
Keep a log of who performed particular Jenkins operations, such as configuring jobs.
This plugin adds an Audit Trail section in the main Jenkins configuration page. Here you can configure log location and settings (file size and number of rotating log files), and a URI pattern for requests to be logged. The default options select most actions with significant effect such as creating/configuring/deleting jobs and views or delete/save-forever/start a build. The log is written to disk as configured and recent entries can also be viewed in the Manage / System Log section.
I spent a few minutes looking through Jenkins various xml and log files, but could not find a log that contained something useful (username and/or timestamp). In this case it seems user auditing isn't built into Jenkins as of yet. Unfortunately it appears that you might not be able to determine who made those changes after the fact.
Is there a way to get the hudson job initiated user name.
Is it possible to get using script shell, py etc.
Lets assume I have the build # which was initiated. I know how to get the latest build info using api but would like to get a user details for a specific job.
Do you think, this will work for hudson? :)
https://wiki.jenkins-ci.org/display/JENKINS/Build+User+Vars+Plugin
Thanks in advance
That plugin will not work with Hudson, unless you download a very old version of the plugin. I'm not sure how many people are still using Hudson and haven't upgraded to Jenkins.
Anyway, when a user manually triggers a build, this is called a "user cause"; there are other types of cause, e.g. SCM trigger.
You can use the JSON or XML API to get the causes for a build, for example:
https://ci.jenkins-ci.org/job/remoting/lastSuccessfulBuild/api/xml?xpath=//action/cause/userId
In this case, this returns the username that caused the build to run.
Though note that there may be multiple causes for a build, and potentially other cause types that use the userId field.
This works in Jenkins, but it should also work in Hudson, but I haven't tested it.
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.
We have an old install of Hudson (ver. 1.379, yes that old...) that hasn't been upgraded yet (and I am not quite sure when and if it will be by the people responsible for it).
There seems to be some place, apparently unaccessible from the web interface, were additional recipients for the email-ext plugin were added...
Problem is, those recipients no longer exist and quite a few people (mostly unrelated to the people who use Hudson) get spammed by bounces from those emails...
For email-ext I get this in the plugin page:
version: 2.12 installed: 2.8
I have looked at the configs and I believe email-ext config should be under "Editable Email Notification" of that job...
I see some of the recipients of those emails but not the person who left, it looks like this was configured elsewhere, maybe manually in some sort of config file.
Where can I look for this?
Thank you!
Puzzled!
There is global configuration. Go to Manage Hudson, then Configure System (the wording my be different based on your version, but you should end up here http://<hudsonurl>/configure. You need to have global administrative permissions to access this, but based on what you are saying, it sound like you do not.
Based on your version of the plugin, under Extended E-mail Notification, you will see Default Recipients. Older versions of the plugin did not have that feature.
Also, under the job configuration itself, there are several places to override/add to the list of recipients, the most buried of which is under the Triggers
Click Advanced... button under Editable Email Notification
For each trigger, click Expand link.
Lastly, it is possible that people are included on the emails cause they were Culprits. In Hudson's terms, these are people who committed to SCM since the last successful build. If the build has been failing since then for a long time, they are just there as culprits. The only way to "reset" the culprits is to let the job build successfully