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.
Related
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.
TeamCity has a feature that (as near as I can figure) is called "service messages". You can see the documentation here. Essentially, it lets me write things like
##teamcity[publishArtifacts '<path>']
to tell the build server to do things. I like this feature. It lets me include the build server steps in my build scripts (and thus in source control) rather than as a configuration on the server. This makes migrating to a different server or recovering from disaster more reliable, "documents" this behavior, and allows multiple builds to leverage it without additional configuration. It's several less things people have to remember to set up when they make new build configurations, and it's much easier to write print '<message>' than it is to load the build server's web interface and drill through several pages looking for the right configuration page.
I've looked around, but I haven't been able to find anything that does this for Jenkins. Does Jenkins have anything similar?
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
We are currently attempting to setup an instance of Jenkins as our build system for our code base. We have multiple jobs setup (all using the same depot) to build different sections of the code.
We would now like to show the submits from all users pertaining to this depot on the main Jenkins screen rather than being able to view the change lists involved with a certain build (e.g. by selecting a certain job and then the link leading to the build information, etc...). I've looked into possible plugins and the closest one I was able to find was the "All Changes Plugin". This is exactly what we would like, but this is only visible when viewing the details of a build (e.g. which CLs were used to create the build), but would it be possible to show this type of information on the main Jenkins page instead?
Thank you in advance for your help.
You could write an extension for the Dashboard View plugin to provide a portlet containing an aggregated list of changes from perforce, though if you aren't experienced with writing plugins then you might be better off using a separate repository browser such as Fisheye or P4Web to display your changes.