When using Cloud Foundry on a Jenkins build server it’s possible to deploy an application with Jenkins to a Cloud Foundry instance. This is supported by the Jenkins Cloud Foundry Plugin
. But in case further Cloud Foundry actions are necessary, another solution is required.
Pushing an application
Per default the Jenkins Plugin supports pushing an application to the Cloud Foundry platform. This is possible via a Post Build Step
in the Jenkins job configuration by using Push to Cloud Foundry
. It’s possible to insert the api url as well as the credentials to push with. Accessing pre defined credentials is also possible.
Running the Cloud Foundry client on command line
In case it’s necessary to run further commands, the Cloud Foundry command line client is necessary. For this the Cloud Foundry client must be installed to the Jenkins host natively. But installing the cf client natively to the Jenkins host might cause some ugly concurrency problems when using it without any further configuration. The Cloud Foundry client stores it’s configuration data in the ~/.cf
folder. This is located within the home folder of the user Jenkins runs with. So all the jobs use the same configuration.
In case an instance
, org
or space
was selected, that might be changed by another Jenkins job. This only occurs in case multiple jobs that use Cloud Foundry run at the same time. One result would be a deployment on the wrong target. Such a situation would occur in case the first job selects a target, then the second jobs does the same with another target. When the first job pushes to the “selected” target, at this moment, this is already the target of the second job. So the first job would push to the wrong target!
In case of multiple steps during the deployment, this maybe results in a partial deployment or setup. Happy debuggin’!
Multi Job Configuration for Jenkins
But there is a way to configure the build environment, so this effect can be avoided.
For this purpose Cloud Foundry simply must be telled to use a specific folder to store its configuration. For this purpose there is the environment variable CF_HOME
. Setting this for each single job is a really redundant and boring job. Furthermore it’s really error-prone kind of work. You might forget to configure a job, or maybe do some copy mis-pasting.
But there is a way to globally configure Jenkins to set the environment variable CF_HOME
. Furthermore Jenkins provides the environment variable WORKSPACE
to each job, pointing at the workspace directory of the Jenkins job. So what’s the solution?
Setting the Manage Jenkins -> Configure System -> Environment Variables
provides a suitable way to set environment variables for all the jobs running on the Jenkins instance. By setting CF_HOME=$WORKSPACE
, Jenkins provides the CF_HOME
variable pointing to its own workspace. So all the configuration data used by the job is stored in the $WORKSPACE/.cf
directory. So there are no effects to other jobs. As the environment variable is set globally, no further misconfiguration is possible and this is working by default
for each Jenkins job.