The issue here is once the first Job in a Jenkins pipeline is done, we need to ask some inputs from user and based on the user Inputs to decide the next job to be triggered(Job2 or Job3)
tried build flow and parameterzied trigger plugin but didn't find any suitable option under these.
Any other plugin or jenkins feature which can help in achieving the above scenario?
There are a few plugins I have tried which collect user input on manually triggered jobs in a build pipeline: Active Choices Plug-in 1.2 and Extensible Choice Parameter 1.3.2.
With Active Choices you define a list of selections and a default value. With Extensible Choice Parameter you can have a text box and a default value.
This is how they work for me in Build Pipeline 1.4.8 on jenkins 1.628
If you run the manual step directly in the pipeline the default is used and other parameters propagate through correctly.
If you open the step there is an option to Build with Parameters which will ask for the user input. This works but other parameters like the build number do not propagate through so the pipeline is broken, and the pipeline screen does not show the status.
Jenkins will never pause and ask a user for inputs. It is an automated build system. It doesn't expect anyone sitting at the console watching the progress.
You can provide "inputs" or parameters when you manually trigger the job, i.e on the first job in your pipeline. You can them pass these parameters to downstream jobs, either through the Parameterized Trigger plugin or through a file copied between jobs.
If you need a human decision in the middle of your build flow, consider Promoted Builds plugin. With this plugin, a human can select a build, and then decide which "Promotion" to execute (which could branch your workflow as you need). The promotions can also be automated if needed, based on criteria and not human input.
Related
Is there a way where to store some metadata from Jenkins pipeline job, e.g:
We have a Jenkinsfile which builds a gradle project, creates docker image and pushes it to google cloud
Then a "Subjob" is launched which runs integration tests (IT) on that docker image. Subjob receives a couple of parameters (one of them - the generated docker image name)
Now sometimes that IT job fails, and I would like to re-run it from the main job view, so idealy:
we have a plugin which renders a custom button in blue ocean UI on the main job
By clicking that button a subjob is invoked again with the same parameters (plugin queries the jenkins api, get params of this job, and resubmits the subjob).
The problem ? How to get/set those parameters. I could not seem to find a mechanism for that, expect artifact storage. I could get away with that by creating a simple json/text file and uploading it as artifact, and then retrieving it in my plugin, but maybe there is a better way?
Stage restart is not coming to Scripted Pipelines so that does not look like ant option.
Maybe you can use the Jenkins API to get the details of the build?
https://your_jenkins_url.com/job/job_name/lastBuild/api/json?pretty=true
Instead of lastBuild you can also use the build number or one of lastStableBuild, lastSuccessfulBuild, lastFailedBuild, lastUnstableBuild, lastUnsuccessfulBuild, lastCompletedBuild
There is a parameters key there with all parameter names and values used in the build.
More details on https://your_jenkins_url.com/job/job_name/api/
Also, any reason you can't use the replay button in the IT job?
I have a Jenkins pipeline job defined. The Jenkinsfile of this job has an input defined using a dropdown. So when the build is triggered the user is requested to select an input.
For manually triggering this is working great!
However, if we want the same job to be triggered by another job as a downstream. How can we do this? providing the input parameters.
Thanks
As #StephenKing pointed out to get setup we need, we have to move away from using input step and make the build parameterized.
The answer I was looking for is here
I am new to Jenkins plugin development. M trying to write a plugin that should be executed before any Multi configuration type job runs in Jenkins.
In this plugin I want to write rules that will check what configuration parameters user has selected while submitting the job, based on selected parameters, I want to decide whether to allow the job to run or to restrict it.
User should be shown reason as to why that job cannot be run in the Console Output.
Does anyone have any ideas which class I need to extend or which interface I need to implement in order to get a hook into Jenkins job run?
You could look at the Matrix Execution Strategy which allows for a groovy script to select which matrix combinations to run. I would think if your script threw an exception it would stop the build.
For background, the multi configuration projects run a control job (or flyweight) which runs the SCM phase then starts all the actual combinations. This plugin runs after the flyweight SCM checkout.
If nothing else, this will give you a working plugin to start from
Disclaimer: I wrote this plugin
Blocked queue job plugin was what I needed
Out of the box that plugin supports two ways to block the jobs -
Based on the result of last run of another project.
Based on result of last run of the current project
In that plugin the BlockQueueItemTaskDispatcher.java extends Jenkin's QueueTaskDispatcher providing us a hook into Jenkins logic to allow or block the jobs present in the queue from running.
I used this plugin as a starting point for developing a new plugin that allows us to restrict project based on parameters selected and the current time. Ultimate goal is to restrict production migrations from running during the day.
Overriding the isBlocked() method of QueueTaskDispatcher gave access to hudson.model.Queue.Item instance as an argument to me. Then I used the Item instance's getParams method to get access to build parameters selected by the user at runtime. Parsed the lifecyle value from it. Checked the current time. If lifecycle was Production and current time was day time then restricted the job by returning non null CauseOfBlockage from isBlocked() method. If that condition was false, then returnedCauseOfBlockage as null allowing the queued job to run.
we use Jenkins as CI tools.
we want to separate login from other process.
we define a job for login, in this job we validate user and if user is valid we get user id.
at other job we need to have user id to generate result,Our problem is how we can send first job result(here:user id) to second one?
You can do this with the use of two plugins:
EnvInject Plugin
Parameterize Trigger Plugin
EnvInject allows you to inject variables into the Jenkins environment so they are available even after that build step.
Parameterize Trigger plugin allows you to pass information in this build job to another build job you want to start as parameters.
Once you've determined the username (I assume in some sort of batch or bash, you don't note the OS) you'll need to write it to a file on the system using a key=value pair. Then use EnvInject to get the value from the file into the jenkins environment. After that you'll use the parameterize trigger plugin to build the next job with parameters. This will require that you check the This build is parameterized box in the second job and that you define the appropriate parameters (perhaps with a default value that you can use to intentionally fail the build if you don't get a good value).
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.