A while ago, Jenkins introduced CSP header which is very restrictive in terms of protecting user from malicious HTML/JS files.
It's possible to relax this rules by temporarily changing "hudson.model.DirectoryBrowserSupport.CSP" property in Jenkins' Script Console, shown for instance here:
Jenkins Content Security Policy
However, I would like to have it set permanently. Unfortunately, I'm yet to find how it should be done properly if someone's using Helm Charts to define Jenkins. Does anyone have working solution?
Any help appreciated.
You can do this using the javaOpts property of the controller.
controller:
javaOpts: -Dhudson.model.DirectoryBrowserSupport.CSP="..."
https://github.com/jenkinsci/helm-charts/blob/jenkins-4.1.3/charts/jenkins/values.yaml#L88
I thinks you can use this parameter
controller:
jenkinsOpts: -Dhudson.model.DirectoryBrowserSupport.CSP="..."
Related
I have a Jenkins server with multiple users that are able to create and modify Global credentials. Is there any way I can audit and see who did what with the credentials - who modified them, who added new creds, etc. Preferably, presented in nice way similar to Job Config History plugin. Thanks
I had a similar question a few days ago. You can use the Audit Trail Plugin (GitHub) to audit changes to credentials. It logs the HTTP requests that modify credentials. However, it doesn't have a "config history"-style visualisation.
(Soon, it may also be able to log what jobs access the credentials)
You can do that using the Job Configuration History Plugin.
Link should be something like:
https://your.jenkins.url/jobConfigHistory/history?name=credentials
What I noticed is that all changes are shown as if they were been done by 'System' - though they all were done by a specific user.
I am willing to trigger my Jenkins job based on status change event from a JIRA issue. I am able to do it using jenkins-trigger-plugin. However I wish to get some more information about the issue like the description of the issue etc. I could see an environment variable named 'JIRA_ISSUE_KEY' but it gives me the key and nothing else.
As of the current release, the issue attribute path is currently resolved from this Issue object. All of jira-trigger-plugin configuration is documented in Jenkins help buttons, which is viewable in Jenkins job configuration.
description for example is retrievable via description path (which would call issue.getDescription() essentially).
I'm develping custom Jenkins plugin.
As part of the development I had to make some changes to the classes and fields of my custom build step.
As a result, each client that updates the plugin has to re-enter the configuration of some of the fields.
I wonder if there is a way to load the old values and map them to the new fields?
Any help will be appreciated.
Cheers,
Nadv
See Hint on retaining backward compatibility in the Jenkins wiki. It covers all relevant cases, e.g. adding/removing/renaming fields.
I'd like some environment variables to be set in Sublime Text when I open the project. This is for the most part just for some plugins that require them to be set.
I believe that there is a feature request for this, but I was still wondering if this isn't possible in some way or another.
http://sublimetext.userecho.com/topic/103881-sublime-project-should-also-be-able-to-set-environment-variable/
I'm asking this specifically in relation with the GoSublime plugin, for which I'd like to change the GOPATH between projects.
I see that you linked my request to sublime userecho.
Unfortunately nothing really happened over there, so I developed my own plugin to do that.
If you are still interested, please look at this:
https://bitbucket.org/daniele-niero/sublimeprojectenvironment
I have also made a pull request to Package Control to make the plugin available with it.
I'm building a group of projects from the SVN. There is a possibility of changing the SVN location time to time. As there are bunch of projects I hope to give the repository url with a environment variable so i can change all the url's easily. Any idea how to do that??
In Subversion Source Code Management, you can use variable in the Repository URL, simply type:
http://my.svn.com/path/to/${VARIABLE}
${VARIABLE} is a job parameters that is defined earlier. Never heard of anyone wanting to use actual environment variables for this, but you can try with the same syntax.
By default, it will give you a red warning that this is not a valid URL. You can disable this warning by going to Manage Jenkins -> Configure System and look for Validate repository URLs up to the first variable name. Put a checkmark there and save.