Skip to content

tmsUpload

Description

This step allows you to upload an MTA file (multi-target application archive) and multiple MTA extension descriptors into a TMS (SAP BTP Transport Management Service) landscape for further TMS-controlled distribution through a TMS-configured landscape. TMS lets you manage transports between SAP BTP accounts in Neo and Cloud Foundry, such as from DEV to TEST and PROD accounts. For more information, see official documentation of Transport Management Service

Prerequisites

Parameters

name mandatory default possible values
credentialsId yes
customDescription no
mtaPath yes
mtaVersion no *
nodeExtDescriptorMapping no
nodeName yes
proxy no
script yes
stashContent no [buildResult]
useGoStep no true, false
verbose no true, false
  • credentialsId - Credentials to be used for the file and node uploads to the Transport Management Service.
  • customDescription - Can be used as the description of a transport request. Will overwrite the default. (Default: Corresponding Git Commit-ID)
  • mtaPath - Defines the relative path to *.mtar for the upload to the Transport Management Service. If not specified, it will use the mtar file created in mtaBuild.
  • mtaVersion - Defines the version of the MTA for which the MTA extension descriptor will be used. You can use an asterisk (*) to accept any MTA version, or use a specific version compliant with SemVer 2.0, e.g. 1.0.0 (see semver.org). If the parameter is not configured, an asterisk is used.
  • nodeExtDescriptorMapping - Available only for transports in Cloud Foundry environment. Defines a mapping between a transport node name and an MTA extension descriptor file path that you want to use for the transport node, e.g. nodeExtDescriptorMapping: [nodeName: 'example.mtaext', nodeName2: 'example2.mtaext', …]`.
  • nodeName - Defines the name of the node to which the *.mtar file should be uploaded.
  • proxy - Proxy which should be used for the communication with the Transport Management Service Backend.
  • script - The common script environment of the Jenkinsfile running. Typically the reference to the script calling the pipeline step is provided with the this parameter, as in script: this. This allows the function to access the commonPipelineEnvironment for retrieving, e.g. configuration parameters.
  • stashContent - If specific stashes should be considered, their names need to be passed via the parameter stashContent.
  • useGoStep - The new Golang implementation of the step is used now by default. Utilizing this toggle with value true is therefore redundant and can be omitted. If used with value false, the toggle deactivates the new Golang implementation and instructs the step to use the old Groovy one. Note that possibility to switch to the old Groovy implementation will be completely removed and this toggle will be deprecated after February 29th, 2024.
  • verbose - Print more detailed information into the log.

Step configuration

We recommend to define values of step parameters via config.yml file.

In following sections of the config.yml the configuration is possible:

parameter general step/stage
credentialsId X
customDescription X
mtaPath X
mtaVersion X
nodeExtDescriptorMapping X
nodeName X
proxy X
script
stashContent X
useGoStep X
verbose X X

Dependencies

The step depends on the following Jenkins plugins

Transitive dependencies are omitted.

The list might be incomplete.

Consider using the ppiper/jenkins-master docker image. This images comes with preinstalled plugins.