Jenkins Queue Job task
TFS 2017
Use this task to queue a job on a Jenkins server.
Note
In Microsoft Team Foundation Server (TFS) 2018 and previous versions, build and release pipelines are called definitions, runs are called builds, service connections are called service endpoints, stages are called environments, and jobs are called phases.
Demands
None
Arguments
Argument | Description |
---|---|
serverEndpoint Jenkins service connection |
(Required) Select the service connection for your Jenkins instance. To create one, click Manage and create a new Jenkins service connection. |
jobName Job name |
(Required) The name of the Jenkins job to queue. This job name must exactly match the job name on the Jenkins server. |
isMultibranchJob Job is of multibranch pipeline type |
(Optional) This job is of multibranch pipeline type. If selected, enter the appropriate branch name. Requires Team Foundation Server Plugin for Jenkins v5.3.4 or later Default value: false |
multibranchPipelineBranch Multibranch pipeline branch |
(Required) Queue this multibranch pipeline job on the specified branch. Requires Team Foundation Server Plugin for Jenkins v5.3.4 or later |
captureConsole Capture console output and wait for completion |
(Required) If selected, this task will capture the Jenkins build console output, wait for the Jenkins build to complete, and succeed/fail based on the Jenkins build result. Otherwise, once the Jenkins job is successfully queued, this task will successfully complete without waiting for the Jenkins build to run. Default value: true |
capturePipeline Capture pipeline output and wait for pipeline completion |
(Required) This option is similar to capture console output except it will capture the output for the entire Jenkins pipeline, wait for completion for the entire pipeline, and succeed/fail based on the pipeline result. Default value: true |
isParameterizedJob Parameterized job |
(Required) Select if the Jenkins job accepts parameters. This job should be selected even if all default parameter values are used and no parameters are specified. Default value: false |
jobParameters Job parameters |
This option is available for parameterized jobs. Specify job parameters, one per line, in the form parameterName=parameterValue preceded by | on the first line. Example: jobParameters: | To set a parameter to an empty value (useful for overriding a default value), omit the parameter value. For example, specify parameterName= Variables are supported. For example, to define the commitId parameter to be the git commit ID for the build, use: commitId=$(Build.SourceVersion). Supported Jenkins parameter types are:
|
retryCount Number of times agent shall retry connection on error |
(Option) This option sets the amount of connection retries when connection failure or error occurs. Default value: '3' |
delayBetweenRetries Timeout between connection retries |
(Optional) This option sets the amount of time between connection retries when an error occurs. This is specified in seconds. Default value: '60' |
failOnUnstableResult Fail when Jenkins build returns unstable result |
If set to true, unstable build result will be treated as a failure. Otherwise, unstable result will be treated as a success. Default value: false |
Team Foundation Server Plug-in
You can use Team Foundation Server Plug-in (version 5.2.0 or newer) to automatically collect files from the Jenkins workspace and download them into the build.
To set it up:
Install the Team Foundation Server Plug-in on the Jenkins server.
On the Jenkins server, for each job you would like to collect results from, add the Collect results for Azure Pipelines/TFS post-build action and then configure it with one or more pairs of result type and include file pattern.
On the Jenkins Queue Job, build task enable the Capture console output and wait for completion to collect results from the root level job, or the Capture pipeline output and wait for pipeline completion to collect results from all pipeline jobs.
Results will be downloaded to the $(Build.StagingDirectory)/jenkinsResults/Job Name/team-results.zip and extracted to this location. Each set of result types collected by the plug-in, will be under the team-results directory, $(Build.StagingDirectory)/jenkinsResults/Job Name/team-results/ResultType/. This is the directory where build results can be published by downstream tasks (for example, Publish Test Results, and Publish Code Coverage Results).
Open source
This task is open source on GitHub. Feedback and contributions are welcome.
FAQ
Q: I'm having issues with publishing my artifacts. How can I view the detailed logs?
To enable detailed logs for your pipeline:
- Edit your pipeline and select Variables
- Add a new variable with the name
System.Debug
and valuetrue
- Save
Q: Which variables are available to me?
A: $(Build.SourcesDirectory)
and $(Agent.BuildDirectory)
are just few of the variables you can use in your pipeline. Variables are available as expressions or scripts.
See Define variables, predefined variables, and Classic release and artifacts variables to learn about the different types of variables.
Q: Task allows me to publish artifacts in deployment job in yaml pipeline, but I am not able to use it in downstream pipeline?
A: Deployment jobs do not have the context of source branches and are hence not appropriate for publishing artifacts. They have been primarily designed to consume artifacts. A workaround would be to isolate that logic into a separate job (with dependencies on your deployment jobs).
Do I need an agent?
You need at least one agent to run your build or release.
I'm having problems. How can I troubleshoot them?
See Troubleshoot Build and Release.
I can't select a default agent pool and I can't queue my build or release. How do I fix this?
See Agent pools.
My NuGet push task is failing with the following error: "Error: unable to get local issuer certificate". How can I fix this?
This can be fixed by adding a trusted root certificate. You can either add the NODE_EXTRA_CA_CERTS=file
environment variable to your build agent, or you can add the NODE.EXTRA.CA.CERTS=file
task variable in your pipeline. See Node.js documentation for more details about this variable. See Set variables in a pipeline for instructions on setting a variable in your pipeline.
I use TFS on-premises and I don't see some of these features. Why not?
Some of these features are available only on Azure Pipelines and not yet available on-premises. Some features are available on-premises if you have upgraded to the latest version of TFS.