Jenkins CI / CD in ICP

As we continue our exploration of IBM Cloud Private (ICP), we wanted to be able to grab some of our existing CI patterns and port them into ICP as opposed to our own Docker Swarm based technology stack.  Someone shared this link with me as a starting point:

https://medium.com/ibm-cloud/running-jenkins-ci-cd-deployments-in-an-ibm-cloud-private-environment-525d5eff33dc

It was a good place to begin, and describes the steps to get started, there were some gaps from this set of instruction because they were created with an older version of what is now ICP.

Tips from my experiences:

1. Do NOT configure Jenkins executors.  The ICP Jenkins chart will automatically spawn disposable slaves to build apps and images.  Be patient while the jobs sit in a pending state until the slave is built, communicates with the master, ... well, for all the magic stuff that makes it work to happen.  If you configured your build step correctly, it will eventually get there.
2. If building a Docker container, the image repository on a default ICP installation has a different address than the one in the instructions.  The correct default repo address is:
   https://mycluster:8500
3. When building your registry credential entry in Jenkins, the name of the variable is flexible.  You can make it something that is meaningful to you, but remember that the username and password are the ICP admin user information you specified at installation time, unless you created your own set of credentials in the namespace.
4. Building and replacing the image in the repo does not update the running container on its own.  Writing a chart and leveraging the Kubernetes native way to manage release lifecycle would be the best native way to handle releases without needing to write it yourself.

This is just the tip of the iceberg, as we explore patterns of end-to-end CI/CD with the ICP platform and the tooling included, and available within the platform.  For Jenkins itself, there are many opportunities for optimizing the pattern, such as triggering deployments from SCM as opposed to needlessly polling the source management system are apparent, but not in the scope of this post as it is merely an addendum to the starter pattern already found available.

Cheers!