Skip to content

cloudFoundryCreateService

Description

Step that uses the CF Create-Service-Push plugin to create services in a Cloud Foundry space. The information about the services is provided in a yaml file as infrastructure as code. It is possible to use variable substitution inside of the yaml file like in a CF-push manifest yaml.

For more details how to specify the services in the yaml see the github page of the plugin.

The --no-push options is always used with the plugin. To deploy the application make use of the cloudFoundryDeploy step!

Parameters

name mandatory default possible values
cloudFoundry/apiEndpoint no https://api.cf.eu10.hana.ondemand.com
cloudFoundry/credentialsId yes
cloudFoundry/manifestVariablesFiles no
cloudFoundry/org yes
cloudFoundry/serviceManifest no service-manifest.yml
cloudFoundry/space yes
dockerImage no ppiper/cf-cli
dockerWorkspace no /home/piper
manifestVariables no
script yes
stashContent no [deployDescriptor]
  • cloudFoundry/apiEndpoint - Cloud Foundry API endpoint.
  • cloudFoundry/credentialsId - Credentials to be used for deployment.
  • cloudFoundry/manifestVariablesFiles - Defines the manifest variables Yaml files to be used to replace variable references in manifest. This parameter is optional and will default to ["manifest-variables.yml"]. This can be used to set variable files like it is provided by cf push --vars-file <file>. If the manifest is present and so are all variable files, a variable substitution will be triggered that uses the cfManifestSubstituteVariables step before deployment. The format of variable references follows the Cloud Foundry standard.
  • cloudFoundry/org - Cloud Foundry target organization.
  • cloudFoundry/serviceManifest - Defines the manifest Yaml file that contains the information about the to be created services that will be passed to a Create-Service-Push cf cli plugin.
  • cloudFoundry/space - Cloud Foundry target space.
  • dockerImage - Name of the docker image that should be used. Configure with empty value to execute the command directly on the Jenkins system (not using a container). Omit to use the default image (cf. default_pipeline_environment.yml) Overwrite to use custom Docker image.
  • dockerWorkspace - Kubernetes only: Specifies a dedicated user home directory for the container which will be passed as value for environment variable HOME.
  • manifestVariables - Defines a List of variables as key-value Map objects used for variable substitution within the file given by manifest. Defaults to an empty list, if not specified otherwise. This can be used to set variables like it is provided by cf push --var key=value. The order of the maps of variables given in the list is relevant in case there are conflicting variable names and values between maps contained within the list. In case of conflicts, the last specified map in the list will win. Though each map entry in the list can contain more than one key-value pair for variable substitution, it is recommended to stick to one entry per map, and rather declare more maps within the list. The reason is that if a map in the list contains more than one key-value entry, and the entries are conflicting, the conflict resolution behavior is undefined (since map entries have no sequence). Note: variables defined via manifestVariables always win over conflicting variables defined via any file given by manifestVariablesFiles - no matter what is declared before. This is the same behavior as can be observed when using cf push --var in combination with cf push --vars-file.
  • 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 - Specific stashes that should be considered for the step execution.

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
cloudFoundry/apiEndpoint X X
cloudFoundry/credentialsId X X
cloudFoundry/manifestVariablesFiles X X
cloudFoundry/org X X
cloudFoundry/serviceManifest X X
cloudFoundry/space X X
dockerImage X X
dockerWorkspace X X
manifestVariables X X
script
stashContent X X

Dependencies

The step depends on the following Jenkins plugins

The kubernetes plugin is only used if running in a kubernetes environment. Transitive dependencies are omitted.

The list might be incomplete.

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

Example

The following Example will create the services specified in a file manifest-create-service.yml in cloud foundry org cfOrg of Cloud Foundry installation accessed via https://test.server.com in space cfSpace by using the username & password stored in cfCredentialsId.

cloudFoundryCreateService(
            script: this,
            cloudFoundry: [apiEndpoint: 'https://test.server.com',
                credentialsId: 'cfCredentialsId',
                serviceManifest: 'manifest-create-service.yml',
                org: 'cfOrg',
                space: 'cfSpace'])

The following example additionally to above also makes use of a variable substitution file mainfest-variable-substitution.yml.

cloudFoundryCreateService(
            script: this,
            cloudFoundry: [apiEndpoint: 'https://test.server.com',
                credentialsId: 'cfCredentialsId',
                serviceManifest: 'manifest-create-service.yml',
                manifestVariablesFiles: ['mainfest-variable-substitution.yml'],
                org: 'cfOrg',
                space: 'cfSpace'])