I would like to have the following workflow in Jenkins:
user clicks 'Build Now'
user fills out build parameters
user clicks 'Build'
information is generated (via a script) and presented to user along with 'Continue' button
user clicks 'Continue' button which simply triggers another job
How can this be done?
in Jenkins Pipeline method use as
script{
currentBuild.displayName = Build_Display (this will be overwrite the Job number)
currentBuild.description = Build_description
}
Alternatively to solution with groovy script plugin, you may generate information together with button with REST command using Rich Text Publisher Plugin - you just don't have to write groovy script, only markup.
It adds a custom html markup to build page after build had been executed.
It allows to configure a message using file, or environment variables.
Use the Execute shell action to create a shell script that sets an environment variable. For example: echo "BUILD_DESCRIPTION=example" >BUILD_DESCRIPTION.setting.
Use the Inject environment variables action to execute the shell script.
Use the Set build description action to set the build description to the variable that was set by the shell script (eg ${BUILD_DESCRIPTION}).
Create an 'Execute system Groovy script' that updates the build description. See How to submit Jenkins job via REST API? which creates a button in the build description.
If I understand correctly, you want a 'Confirmation Button', or a 'Are you Sure' button:
In Jenkins pipeline, you can do that by asking for user input.
timeout(time: 15, unit: "MINUTES") {
input message: 'Are the info correct?'
}
The problem with this approach is that you keep a Jenkins worker (or process) running for a maximum X minute if the user doesn't take any action, this can make Jenkins create a long queue of builds.
Here is the documentation.
If i get what you want to do right (more from the caption and less from the description) you should just use this Publisher Plugin:
if it doesn't help please try adding more information to your question.
Related
I'm trying to get a parameterized build running with Jenkins. All the tutorials point to a This build is parameterized check box like here. Other tutorials point to this documentation but after searching around I can't figure out how to get the check box to actually show up. Am I missing something?
Edit: Figured it out - the This build is parameterized check box was there all along under a different header. The Office 365 Connector plugin creates a new header that splits the general options in half. I thought that the check box was being used specifically for that plugin, but the header was just misleading.
If you looking for "This project is parameterised" option that is a native Jenkins functionality. You don't need any plugin for that. It should be under the General tab.
see my plugins list; I have not installed any plugin.
In Jenkins 2.330 (without related plugins) we see no option like This build is parameterized or This project is parameterized at repo level.
Jenkins does draw a Build with parameters button for us instead of the usual Build button, provided the Jenkinsfile declares some parameters.
At branch level, View Configuration button then shows a greyed out, enabled checkbox This project is parameterized (it is not greyed out in repos where the Jenkinsfile declares no parameters, but we opted to configure things at above-repo level so it is not clickable)
Example Jenkinsfile:
#!groovy
properties([
parameters([
booleanParam(name: 'destroy', defaultValue: false,
description: 'delete images', )
])
])
node('normal') {
if (this.env.destroy == 'true') {
sh 'echo DESTROY MODE'
} else {
sh 'echo DRY RUN'
}
}
Might have to click Scan Multibranch Pipeline Now after adding those parameters:
I am trying to send an email in a post-build action, with the content set to some results I computed in a build action. I cannot seem to be able to pass variables from the shell code to any post-build actions.
I have tried with EnvInject, but haven't managed to make it work.
What am I missing?
As it always happens, I managed to find the solution right after I posted the question.
I managed to solve it by having something like this in the shell script bit:
EMAIL_CONTENT=$(cat <<EOF
Some content here.
Some content there.
EOF
)
EMAIL_RECIPIENTS="someone#example.com"
touch email_properties
echo "EMAIL_CONTENT=${EMAIL_CONTENT}" >> email_properties
echo "EMAIL_RECIPIENTS=${EMAIL_RECIPIENTS}" >> email_properties
And then, in the post-build action, I used Trigger parametrized build on other projects, with the Parameters from properties file option in order to trigger some other job whose only purpose is to email me those credentials. It's a bit of a work around, but it works.
When I run a manual build, I'd often like to mark it with documentation to show why I ran it. Is this feature available with a plugin?
thank you!
I would approach this by adding a build parameter as a string, as above, then use the Description Setter Plugin to set it from that parameter. We use something like this for the regex:
^\++ : BUILD DESCRIPTION : GERRIT_CHANGE_OWNER_EMAIL=([^#\s]*)\S*, BUILD_USER_EMAIL=([^#\s]*)\S*, GERRIT_BRANCH=(\S*), GIT_COMMIT=(\S{8}).*$
and this for the description:
\1\2, \4, \3
As a result we get:
jspain, 0ee3198b, master
or when it fails, we get:
Failed due to timeout.
wayvad, fc7bdf2a, master
this "Failed..." text comes from the Build Timeout Plugin
I am not aware of a plugin that can do this, and after a brief search I could not find one to do what you describe.
You can mimic this behavior by adding a string parameter in the job that takes a default value of automatically started when it's normally run, but that you can change to my reasons for this build when starting it manually.
You could then use a batch (or groovy or ) build step to print the contents of that parameter into the build log. If you do some sort of SCM checkout I'm not sure how close you can get it to print to the line that contains the username that started the job, however you can click on the view parameters button in the job build and see what was in the field quickly without having to parse the logs.
The downside of this is that parameter would have to be added to each job.
I have Job on Jenkins ver. 1.500 with build ID parameterized.
I want to use this parameterized value in the subject line of section "Post-build Actions".
If I try to access using $ID or ${ID} its printing it as plane string "$ID"[without value substitution]. I am aware of environmental variable $BUILD_NUMBER, which is giving the current job #number.
Can someone share, how to achieve this simple task of reading build number?
$PROJECT_NAME - Job # $ID built at $BUILD_ID - $BUILD_STATUS!
--Thanks,Prashant
It sounds like you are talking about Editable Email Notification post-build action. It has it's own way of referencing variables.
Variables that are available within the plugin, can be referenced directly as ${VARIABLE}, in both the body of the email and the subject line. For a list of available variables, click on the ? icon for on-page help.
However to access other environmental variables, including the parameters used by the build, you have to use the format ${ENV, var="VARIABLE"}, so in your case, it would be ${ENV, var="ID"}
I have Jenkins job that has execute shell part in which I have some variable
BUILD that is dynamically populated.
After build execution, I want to pass this variable to email-ext plugin Default Content to able to show it's value.
I've tried couple of ways without a success:
Passing this ${BUILD} value in Default Content is not recognized (Only Jenkins environment variables are visible in this context)
Defined new Jenkins global environment variable and tried to overwrite its initial value in shell context which apparently is not possible
Any idea on how to do this?
In my case, I'm not the administrator, then I can't install plugins. But can be done with a workaround.
In Content Token Reference help you can found an useful tool.
${PROPFILE,file="FILENAME",property="PROPERTYNAME"}
Expands to the value of a property in a property file. The filename is
relative to the build workspace root.
Then save values in a property file inside Build > Execute Shell:
rm -f ${WORKSPACE}/env.properties
touch ${WORKSPACE}/env.properties
store="/opt/current/store"
echo "store.folder=${store}" >> ${WORKSPACE}/env.properties
echo "${store}"
And read it from Post-build Actions > Editable Email Notification with:
${PROPFILE,file="env.properties",property="store.folder"}
Simple and easy:
In your "Execute Shell"
echo "test log" > /some/file/path/logFile.txt
Then in your "Editable Email Notification-Default Content"
${FILE,path="/some/file/path/logFile.txt"}
Build and you will receive a email with content "test log"
To see more email tokens, you can click the question mark beside "Content Token Reference" in "Editable Email Notification" section.
Use EnvInject Plugin to read the variable from a file, after you write that file in the "shell part".
In general, environment variables never go from child process back to parent process, this is basic feature of both Windows and Unix operating system families. Child always gets a copy of parent's environment, and if it modifies it, it modifies it's own copy (which is then copied to any child process if it launches any, etc). But to get changes back, some other method must be used, such as child writing desired changes to a file, which is then parsed by parent, which can then edit it's own environment based on it.
You can pass build parameters to email ext plugin by using:
${ENV,var="CAPITALIZED:VAR_NAME"}
In that way i see the variable value in the received mail.