In Jenkins ver. 2.121.3 using pipeline trying to delete the file. Its giving script not permitted error message.
Is there a alternate way to delete the file in Jenkins with-out using OS command?
Scripts not permitted to use method java.io.File delete. Administrators can decide whether to approve or reject this signature.
[Pipeline] End of Pipeline
org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use method java.io.File delete
Pipeline code
stage('Delete test.zip file') {
if (fileExists('test.zip')) {
new File('test.zip').delete()
} else {
println "test.zip file not found"
}
}
There are several alternative ways:
By means of jenkins shared library you can wrap this code up to function or class:
#!/usr/bin/groovy
package org.utils
class PipelineUtils {
static def deleteFile(String name) { new File(name).delete() }
}
in your pipeline script, you need to import the library:
#Library('your-jenkins-library')_
import static org.utils.PipelineUtils.*
deleteFile('test.zip')
As #Sean has suggested to approve the script via "Manage Jenkins > In-process Script Approval".
There is File Operations Plugin:
fileOperations([script.fileDeleteOperation(excludes: '', includes: 'test.zip')])
There is Workspace Cleanup Plugin, but you need to find suitable exclude-patterns, otherwise this will clean all files:
def new_exclude_patterns = [[pattern: ".git/**", type: 'EXCLUDE']]
cleanWs deleteDirs: false, skipWhenFailed: false, patterns: new_exclude_patterns
If you are running pipeline on linux slave (or windows slave with sh in path), you may use the below call to avoid interactive prompts.
sh(""" rm -rf "$directory" """)
Navigate to /scriptApproval/ (Manage Jenkins > In-process Script Approval) and approve the script.
Another way since Java 1.7/Groovy ?.? is:
Files.delete(Path.of(FQFN))
Related
Can someone please help me with the open source puppet?
I want to provide a jar file to a windows client and execute the .jar file with the command line.
The .jar file is actually an update for an application which is running as a service.
I am poorly familiar with the puppet language but would guess something like this to execute the jar file:
exec { 'jar_execution':
command => 'cmd.exe /c java -jar foo.jar',
}
Should this be part of the manifest which could look like this?
service { 'fooservice':
name => foo_service,
ensure => running,
enable => true,
}
file { 'foo.jar':
path => 'C:/foo/temp/foo.jar',
ensure => file,
source => "puppet:///modules/foo/foo.jar",
}
exec { 'jar_execution':
command => 'cmd.exe /c java -jar C:/foor/temp/foo.jar',
}
And how does the agent actually run this command?
There are few architectural considerations:
Use archive resource (from archive module) instead of: file with your .jar in your module's .git history.
Have all artifacts (e.g. binary files) served by another service like Apache Archiva, Nexus or Artifactory or even Puppet Server itself. If the .jar is not developed by your company, you may want to use the authoritative source with maybe some internal caching.
Name your resources in a way that are global to your whole infrastructure, otherwise you may have events that notify themselves and produce undesired outcome.
Order of resources in puppet doesn't matter. You want to order the resources the way it makes sense to you and use the before, after, require, notify to ensure dependency.
I would recommend having binaries files outside of a module, as binaries are not supposed to be versioned. You would probably have another service that can serve files, or even your puppet infrastructure can provide those packages, in the similar way it provides the puppet-agent itself, regardless if you use Puppet OSS or Puppet Enterprise.
archive { 'C:/foo/temp/foo.jar':
source => https://location/to/your/.jar,
}
exec { 'C:/foo/temp/foo.jar': # notice in resource name recommended to use / not \
command => 'cmd.exe /c java -jar C:/foor/temp/foo.jar',
refreshonly => true # this one executes exec only if the file was re-downloaded (maybe it's signature has changed), or the file was removed from disk and was re-downloaded.
onlyif => 'test -f C:\foo\temp\foo.jar' # or some command that guards you to not run this .jar every time you run puppet
subscribe => Archive['C:/foo/temp/foo.jar'],
notify => Service['foo_service'] # most probably you need to restart the service after you ran the .jar, otherwise you wouldn't have added in your question.
}
service { 'foo_service':
ensure => running,
enable => true,
}
I notice that in your example you don't need to remove your .jar after being executed. In case you need that, another exec command can remove the file downloaded in the same
Good afternoon, friends from Stack !
I am running a SonarQube in my pipeline in a jenkins instance. I have an issue and I'm following the documentation and I am kid of new to this.
https://docs.sonarqube.org/display/SCAN/Analyzing+with+SonarQube+Scanner+for+Jenkins
But I have a Windows slaves. And everytime I configure it according to the documentation I get an error...
[Sonar-Pipeline] Running batch script
C:\Program Files (x86)\Jenkins\workspace\Sonar-Pipeline>C: \Program Files (x86)\Jenkins\tools \hudson.plugins.sonar.SonarRunnerInstallation\SONAR_RUNNER\bin\sonar-scanner
'C:\Program' not‚ recongnized as an internal or external command.
After which I beleive that there is a space here and Jenkins is trying to execute only 'C:Program ' as the above shows. Does any body now this?
This is my pipeline...
node {
stage('SonarQube analysis') {
// requires SonarQube Scanner 2.8+
def scannerHome = tool 'SONAR_RUNNER';
withSonarQubeEnv('SonarQube') {
bat "${scannerHome}/bin/sonar-scanner"
}
}
}
So this is what I am trying to execute according to the documentation. The only thing that is asked, because I am using only windows is to switch to bat instead of sh on scannerHome execution. Because it is a pipeline also and not a normal option. And I do have all the files too.
Please use below code to run the sonar-scanner on windows
node {
stage('SonarQube analysis') {
// requires SonarQube Scanner 2.8+
def scannerHome = tool 'SONAR_RUNNER';
withSonarQubeEnv('SonarQube') {
bat "\"${scannerHome}\\bin\\sonar-scanner.bat\""
}
}
I'm using Jenkins ver. 2.150.1 and have some freestyle jobs and some pipeline jobs.
In both job types I am using the emailext plugin, with template and pre-send scripts.
It seems that the build variable, which is available in the freestyle projects, is null in the pipeline projects.
The pre-send script is the following (just an example, my script is more complex):
msg.setSubject(msg.getSubject() + " [" + build.getUrl() + "]")
There is no problem with the msg variable.
In the freestyle job, this script adds the build url to the mail subject.
In the pipeline job, the following is given in the job console:
java.lang.NullPointerException: Cannot invoke method getUrl() on null object
The invocation of emailext in the pipeline job is:
emailext body: '${SCRIPT, template="groovy-html.custom.pipeline.sandbox.template"}',
presendScript: '${SCRIPT, template="presend.sandbox.groovy"}',
subject: '$DEFAULT_SUBJECT',
to: 'user#domain.com'
I would rather find a general solution to this problem (i.e. Access the build variable in a pipeline pre-send script), but would also appreciate any workarounds to my current needs:
Access job name, job number, and workspace folder in a pipeline pre-send script.
I have finally found the answer -
Apparently for presend script in pipeline jobs, the build object does not exist, and instead the run object does. At the time I posted this question this was still undocumented!
Found the answer in this thread
Which got the author to update the description in the wiki:
run - the build this message belongs to (may be used with FreeStyle or Pipeline jobs)
build - the build this message belongs to (only use with FreeStyle jobs)
You can access the build in a script like this:
// findUrl.groovy
def call(script) {
println script.currentBuild.rawBuild.url
// or if you just need the build url
println script.env.BUILD_URL
}
and would call the script like this from the pipeline:
stage('Get build URL') {
steps {
findUrl this
}
}
The currentBuild gives you a RunWrapper object and the rawBuild a Run. Hope this helps.
I'm generating a Jenkins pipeline using a script. This pipeline is then loaded and executed. This works fine on any linux node and with sh statements etc.
I have now encountered an issue executing this on a windows node with the powershell and bat steps:
The checkout scm works fine, but any steps with the powershell or bat steps hang indefinitely. Copying the data from the generated file and replaying everything in a single Jenkinsfile works as expected.
An example of what is running (excluding the library):
"Main" Jenkinsfile:
def pod_label = "my_linux_node"
node(pod_label) {
stage("Checkout") {
checkout scm
}
stage("Pipeline generation") {
// genarate pipeline and save in "gen_pipeline.groovy"
}
stage("Run Pipeline") {
pipeline = load "gen_pipeline.groovy"
pipeline.run_pipeline()
}
}
Script1:
def run_pipeline(){
node('my_win_node') {
checkout scm
bat "echo foobar"
}
}
return this
I'm using Scriptler plugin, so I can run a groovy script as a build step. My Jenkins slaves are running on windows in service mode. With scriptler, I don't need to use windows batch scripts.
But I have trouble to get the environment variables in a build step... This is working:
System.getenv("BASE")
Where BASE is part of the env-vars on jenkins startup. However, I would like to get
%JOB_NAME%
If I'm adding an "Execute Windows batch command" build step:
echo %JOB_NAME%
It works.
If I'm adding a scriptler script as a build step with the same settings:
println "JOB_NAME: " + System.getenv("JOB_NAME")
I'm getting:
JOB_NAME: null
So how can I reach the injected environment variables from a groovy script as a build step?
build and listener objects are presenting during system groovy execution. You can do this:
def myVar = build.getEnvironment(listener).get('myVar')
You might be able to get them like this:
def thr = Thread.currentThread()
def build = thr?.executable
def envVarsMap = build.parent.builds[0].properties.get("envVars")
On jenkins 2.x, with groovy plugin 2.0, running SystemGroovyScript I managed to get to build variables, as below:
def build = this.getProperty('binding').getVariable('build')
def listener = this.getProperty('binding').getVariable('listener')
def env = build.getEnvironment(listener)
println env.MY_VARIABLE
If you are using goovy from file, simple System.getenv('MY_VARIABLE') is sufficient
The Scriptler Groovy script doesn't seem to get all the environment variables of the build. But what you can do is force them in as parameters to the script:
When you add the Scriptler build step into your job, select the option "Define script parameters"
Add a parameter for each environment variable you want to pass in. For example "Name: JOB_NAME", "Value: $JOB_NAME". The value will get expanded from the Jenkins build environment using '$envName' type variables, most fields in the job configuration settings support this sort of expansion from my experience.
In your script, you should have a variable with the same name as the parameter, so you can access the parameters with something like:
println "JOB_NAME = $JOB_NAME"
I haven't used Sciptler myself apart from some experimentation, but your question posed an interesting problem. I hope this helps!
The only way I could get this to work (on Linux) was to follow this advice:
https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+System+Groovy+script
import hudson.model.*
// get current thread / Executor and current build
def thr = Thread.currentThread()
def build = thr?.executable
// if you want the parameter by name ...
def hardcoded_param = "FOOBAR"
def resolver = build.buildVariableResolver
def hardcoded_param_value = resolver.resolve(hardcoded_param)
println "param ${hardcoded_param} value : ${hardcoded_param_value}"
This is on Jenkins 1.624 running on CentOS 6.7
Jenkins 2.x has the global variables. env is one of them from any script...
println env.JOB_NAME
More at https://build.intuit.com/services-config/pipeline-syntax/globals#env
One thing to note, if you are using a freestyle job, you won't be able to access build parameters or the Jenkins JVM's environment UNLESS you are using System Groovy Script build steps. I spent hours googling and researching before gathering enough clues to figure that out.
In System Groovy Script (Jenkins 2.89), I was able to use the environmental variable to disable another Jenkins job
import jenkins.*
import jenkins.model.*
def env = binding.build.environment
Jenkins.instance.getItemByFullName(env.job_name).setDisabled(false)
I also added a conditional step so as to either enable or disable another Jenkins job.
Thanks #Allan Lewis, your comment was helpful.