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
Related
I have a job creator job that creates other jobs in jenkins and I would like to use the created jobs name in the description.
For example for name "JobXX" i would like to have:
"This is documentation for JobXX etc.."
In "Execute shell" build step I can refer to the jobs name via $JOB_NAME parameter but that does not seem to work in the description field.
Any ideas on how to do this? Or if it's even possible?
Never used it, but take a look to the Project Description Setter Plugin:
https://wiki.jenkins.io/display/JENKINS/Project+Description+Setter+Plugin
In this blog it explains better how to use it:
http://www.tothenew.com/blog/setting-dynamic-project-description-and-build-description-in-jenkins/
Among the different variables you can use there is {PROJECT_NAME} which fits your needs.
Besides this, this plugin allows you also to automatically set descriptions to each specific build.
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.
I have parametrized build job in Jenkins. It has configured SCM polling and the build job is started after new commit.
Parameters for this build job are location profiles defined in main pom.xml. Count of these profiles is static and persistent. So after every commit I need to build a project for the same profiles. One profile is started for one build.
It is able for manual triggering when I write profile name and start the build job. But after new commit this build job is started without parameters. So is there any way how to define list of parameters for build job - one parameter per one build.
An SCM change will trigger a related Jenkins job. Once. That's it.
When that job is triggered, and is configured with parameters, it does have default parameters.
For string parameters, it's the default value entered in configuration page (if you haven't entered one, the default is just that: none).
For single choice-style parameters, it's the top-most value.
For multi choice-style parameters, again, unless a default is provided in configuration, it's nothing.
If what you want is to trigger multiple runs of the same build for the same SCM change, then you've configured your jobs wrong.
Either create a matrix job, and configure an axis for every "profile" as you call it.
Or create multiple jobs, and chain them, so that first is triggered by SCM change, and the rest are triggered in sequence
If you only want to specify one default string that should be picked up while building using Poll SCM feature, then you should try using the following method:
Select the following options in Extended Choice Parameter:
In Simple Parameter Types section, go for Single Select in Parameter Type
Instead of Choose Source for Value, go for Choose Source for Default Value. Now enable the radio-button named Default Value. Enter whatever string you want to specify. Build will pick-up the given string as the default one.
Hopefully, it should work. At least, it works when i use Build periodically option. :)
Is there a way to restrict a build step for a user. I have added a build step using the templates plugin, this template is for the deployment.
I do not want any users who has access to create a job or modify a job to be able to use this build step. The new build step that has been added should only be used by the the administrator.
If people can modifying Job configuration, they can get around any limitation you would place.
If your step can be executed post-build, I suggest to take a look at Promoted Builds plugin. The promotions can be configured to be limited to certain users only. But again, if a user has ability to change job configuration, they can overcome that easily.
The only way I can think of, is to have an external script (or preferably a compiled program than cannot be simply "read" with text editor) that is expecting a password that only you now, before executing whatever secret stuff that you want.
My question may be silly but I've been trying several ways and I still can't do what I want, i.e.:
use the scp target of Ant to target a remote machine and execute
a script there
this script creates a dynamic list of files
get this list of files (only their names) back in Hudson to use it in the next build step (another scp from Ant)
I tried to use environment variables but they are interpreted by Hudson so I'm stuck here...
Globally my question would be: how to get a result from an Ant build step ?
Thanks for your ideas,
Emmanuel
You may find File parameter useful. This allows you to create an input file, pass it to build. You may need to write script/ant script to process the file though.
In the long term you may evaluate a Hudson farm. This will allow to create tasks that span multiple machines , pass results around. (https://wiki.jenkins-ci.org/display/JENKINS/Plugins)
You can get the ID(s) of the job that triggered your job via the API and fetch their status.