When I trigger a job remotely using the API the job on jenkins say: "Started by remote host IP". But my jobs can trigger for different reasons and from different sources so it would be great if I in Jenkins could look at a job and directly see the trigger reason.
I know I could pass a string parameter and then in each job view the parameters - but that's not very visible. I would like to preferably see it already in the list of all jobs. Something like: Reason: X Source: N.
Is there any way to do this ?
I have noticed that our release jobs take a version parameter that shows like I want - but I don't want to abuse that since these runs are not releases.
Build Name
I think you want to set the build name to a different one like here:
So you can use the Build Name Setter Plugin and use the build step Update build name.
For your case you can use:
#${BUILD_NUMBER} ${BUILD_CAUSE}
Cause Badge
Have a look on Build Trigger Badge Plugin, it represents with an icon the reason of the build.
Extract the job cause
One possibility to extract the job cause is to use groovy, currentBuild is injected into the runtime and includes information about the causes and so on.
This prints the first (!) cause:
println ("Cause: " + currentBuild.causes[0])
Unfortunately, even with the Build Trigger Badge Plugin activated http://<Your Jenkins>/job/<Your job's name>/api/xml doesn't show the trigger cause.
You could parse the job's HTML for:
<div class="middle-align build-badge" style="width: 100%;">
<img width="16" height="16" src="/plugin/buildtriggerbadge/images/user-cause.png"
alt="Trigger UserIdCause : Started by user YourUser" title="Started by user YourUser">
</div>
See also the EnvInject Plugin:
This plugin also exposes the cause of the current build as an environment variable.
Related
I configured a job on Jenkins which trigger some script in python and does some tests. In the end, it gives results inside an artifact folder (so we can keep X amount of results at any time), which I am showing presenting with a Publish rich text message post-build action. Here is the pretty straight forward code:
<br/>
<h2>Results:</h2>
<iframe src=./artifact/artifacts/results.html width=1100 height=1000></iframe>
This works correctly inside a job build, but if you go inside the main page of the job, I get a 404 not found since it cannot find the file. I understand that the error is correct, since it cannot find any artifact folder if we are not within a build of the said job. My question is how can I have different settings depending if we are inside the main page of the job vs a build of the job ?
I checked online and found that there is a lastSuccessfulBuild variable I can use but then I think it will show the same results no matter which build we are, which is something I do not want.
I am using the Jenkins Delivery Pipeline plugin. I have some parameterized builds that are manually triggered. If I trigger a build from the project page, the build shows a screen where parameters need to be defined (as expected). However, when I start a parameterized build from the Delivery Pipeline plugin, it just starts the build without offering a screen. This is strange behavior, is it possible to get the pipeline plugin to show the parameterized build screen?
Thanks for your help!
I'm answering this question in general.
You need to use the Parameterized Trigger Plugin, or use the Build Pipeline Plugin. This issue with Delivery Pipeline plugin is still being solved by the Jenkins Team. See this link for the update about the issue at https://issues.jenkins-ci.org/browse/JENKINS-25685. You can get to know when it gets resolved from that link.
You can use the Build Pipeline plugin if it can be incorporated in your use case. There was a similar issue for the Build Pipeline plugin which is fixed now. It got fixed within 22 days (https://issues.jenkins-ci.org/browse/JENKINS-25427, https://github.com/jenkinsci/build-pipeline-plugin/pull/56). You can just hope that the same issue with the Delivery Pipeline plugin is fixed soon.
Can you provide me the version of Jenkins, environment and the plugin version? I can update my answer based on the answers you give.
When you are using the Delivery Pipeline plugin, and you have manually-triggered parameterized builds, as long as you configure the upstream job to pass along the parameters to the downstream job, when the "build trigger button" is clicked on the pipeline view page, the parameters are automatically passed along.
For instance, let's say you have a setup like this:
Compile_Project ---> Deploy_Project
Let's assume that you are passing a variable called versionNumber from the Compile_Project to the Deploy_Project jobs. Let's also assume that you're using Subversion for your SCM, and your versionNumber looks like 1.0.${SVN_REVISION}. ${SVN_REVISION} is automatically provided by Jenkins, so your version number will look something like 1.0.1234, where 1234 is the commit number provided by Subversion.
On your Delivery Pipeline view, let's say that it's configured to show 3 pipeline instances, and that manual triggers are enabled in the view settings. Your pipeline view page might look something like this (yay ASCII art!):
Compile_Project ---> Deploy_Project (>)
Compile_Project ---> Deploy_Project (>)
Compile_Project ---> Deploy_Project (>)
In this case, I'm using (>) to represent the manual trigger button. The button on the bottom would attempt to deploy version 1.0.1234, the middle button would attempt to deploy version 1.0.1235, and the top button would attempt to deploy version 1.0.1236, assuming your project has gotten consecutive SVN commits.
In order to pass the parameter from the Compile_Project to the Deploy_Project job, you need to do the following. (Note: it sounds like you've already done this part, but I'm including it just in case you might have missed a step, and also for the sake of completeness.)
In the Compile_Project job's configuration, as a Post-Build Action, choose "Build other projects (manual step)". In the "Downstream project names" box, enter Deploy_Project, and then from the "Add Parameters" drop-down, select "Predefined Parameters". In the "Parameters" text area that appears, create a parameter to pass along, which I'll call VERSION_NUMBER. What you'll enter in the text area is then VERSION_NUMBER=1.0.${SVN_REVISION}. This will enable the parameter to get passed from the Compile_Project to the Deploy_Project. However, you're not quite done yet.
In the Deploy_Project job's configuration, you need to set it up to accept the parameter you're passing into the job. To do so, configure the Deploy_Project, and check the "This build is parameterized" checkbox. Then add a String parameter from the "Add parameter" drop-down. In the "Name" field, enter VERSION_NUMBER. At this point, you can then use ${VERSION_NUMBER} in the Deploy_Project's configuration wherever you need in order to specify the correct version number of the project to deploy.
So I need a job parameter to contain the next build number as its default value. This is mostly for information purposes to the user, so could go into the job description instead.
I've taken a look at dynamic parameters, to little avail.
Obviously, environment variables like BUILD_NUMBER are not set until the job has started building.
This is a stand alone job.
Edit:
The purpose of this parameter is just to provide information to the user who is kicking off the job. The parameter will contain a path to a directory that will be created during the job execution. The name of that dir will contain the build number that created it. /Testing/myTest_job$BUILD_NUMBER
If you want to have a generic description, you can user the Description Setter Plugin.
Install the plugin
Add Build Step "Set build description" as first Build Step
Set "Description" to /Testing/myTest_job${BUILD_NUMBER} and leave "Regular expression" blank
Alternative:
I would suggest to use the post build step "archive artefacts". This will provide the files your job creates as i.e. download link:
http://jenkins.foo.bar/job/example/lastSuccessfulBuild/artifact/yourfile.exe
In a single Jenkins job, we can trigger a build by specifying a schedule and also by polling. But then, in both the cases, the build is triggered, and the deploy operation that I have configured as a post-build step (using PostBuild Task plugin) also happens. I want that the build happens whenever a change is detected by polling, but deploy should happen only according to the schedule I have provided.
Is it possible to do it in a single job, or do I have to configure 2 separate jobs for them ?
You said you are using PostBuild Task plugin. This allows to do a regular expression on the console log to determine whether to execute a task or not.
Builds started by schedule will have Started by timer at the top of the log. All you need to do is add this expression to your PostBuild step under "Log Text" field. If you are already using some criteria in there, click "Add" button to add another "Log Text" field, and use the "AND" operator between them
It will be cleaner to do it in 2 jobs. However, if you really need to have it in one job, you could use a combination of Jenkins plugins to do the job.
Use EnvInject Plugin to expose the BUILD_CAUSE and/or BUILD_CAUSE_SCHEDULED* environment variable(s). (This may not be necessary, you might be able to reference the Jenkins variables within the Jenkins configuration by default)
Use Flexible Publish plugin, post-build action, to set up a conditional publish step when BUILD_CAUSE == SCHEDULED, or when BUILD_CAUSE_SCHEDULED == true. (Just test one condition.) Note that you'll need to use Jenkins' expression syntax, like so:
${ENV,var="BUILD_CAUSE_SCHEDULED"}
* BUILD_CAUSE_SCHEDULED is not its real name, you'll need to find this out on your own, sorry.
I am using jenkins for continous integration.
For my build purpose, i triggering email using Ant task. I am not able to find an environment variable to pass ant for sending email build status(success/failure/stable).
i want to know how can i get environment variable for build status?..if not available, what is the alternative option for build status?
Thanks in Advance
varghese
Why use ANT to send emails from Jenkins when you have two great plugins that does just that?
The default mail notification is quite good, and if you would like to have more control
I suggest using the Email-ext plugin which is very comprehensive.
If still wish to use ANT to sent your mail-notifications including the status
you will have to break your process into two steps,
where the first part runs the build and the second one runs the ANT script to report the status.
In this case, you will need to trigger the second job from the first job via the Parameterized Build plugin -
see my answer here:
trigger other configuration and send current build status with Jenkins
The build status is not set until the job has finished running, so there is no easy way to push build status to a process triggered within the build itself. You could pull build status via the API, but this would have to be an externally triggered process due to the constraint mentioned above. Any reason you aren't using the built in email support or one of the excellent email extension plugins such as this one?