In this blog, I am going to focus on the way how, the data can be injected dynamically into the MTA extension files using Jenkins pipeline for the deployment to the cloud foundry.
For instance, we have the credentials stored in the Jenkins instance, and we can fetch the credentials and then finally load them into the MTA extension file as shown below:
def functionSample(extensionFiles){
unstash 'deployDescriptor'
extensionFiles.each { fileName ->
def mtaData = readYaml file: fileName
withCredentials([
usernamePassword(credentialsId: globalPipelineEnvironment.configuration.general.serviceBrokerCredentialsId, usernameVariable: 'SERVICEBROKER_USERNAME', passwordVariable: 'SERVICEBROKER_PASSWORD'),
]){
mtaData['modules'].each{module->
if (module['name']=='module1'){
module['parameters']['service-broker-user'] = "${SERVICEBROKER_USERNAME}"
module['parameters']['service-broker-password'] = "${SERVICEBROKER_PASSWORD}"
module['properties']['SBF_BROKER_CREDENTIALS'] = "{ \"${SERVICEBROKER_USERNAME}\": \"${SERVICEBROKER_PASSWORD}\" }"
}
}
}
sh "rm $fileName"
writeYaml file: fileName, data: mtaData
}
stash name: 'deployDescriptor'
}
In the above sample from the Jenkins pipeline, it makes use of the Piper library. DeployDescriptor is the step from the piper library, which contains all the extension files.
Sample example of a mta extension file is shown below:
_schema-version: "3.1"
extends: cloud-test
ID: cloudci-test
modules:
- name: module1
parameters:
host: cloud-test
health-check-timeout: 80
- name: module2
parameters:
service-broker-user:
service-broker-password:
In the above mta extension file, the parameters namely service-broker-user and service-broke-password are left null, but using the pipeline, we are fetching the credentials from the Jenkins instance and injecting the parameter values into the extension files dynamically during the build from the Jenkins pipeline.
Hence, each space in a cloud foundry can have its own extension file with its custom values.
