anchor.diff:  ----
   
   The build that will be performed is an s2i binary build. The input of the build is the jar that has been built locally and the output of the build is an ImageStream that is configured to automatically trigger a deployment.
  +
  +To deploy the container image created in the above step to OpenShift, follow these commands:
  +[source, subs=attributes+]
  +----
  +oc get is
  +oc new-app --name=greeting <project>/openshift-quickstart:1.0-SNAPSHOT
  +oc get svc
  +oc expose svc/greeting
  +oc get routes
  +curl http://<route>/greeting
  +----
  +
  +In the above, `oc get is` will list the image stream created.  It should be tagged as <project>/openshift-quickstart:1.0-SNAPSHOT.
  +
  +Similarly, `oc get route` will list the route URL for the exposed service "greeting" so that you can use it to test the application.
   
   === Non S2i Builds
   
  
positive.code: The configuration items that are available can be found in: `io.quarkus.kubernetes.deployment.OpenShiftConfig` class.
  Furthermore, the items provided by `io.quarkus.deployment.ApplicationConfig` affect the OpenShift resources.
  
  === Building
  
  Building is handled by the link:container-image#s2i[container-image-s2i] extension. To trigger a build:
  
  [source, subs=attributes+]
  
negative.code: quarkus.container-image.builder=jib
  ----
  
  === Build and Deploy (in a single step)
  
  If the OpenShift extension was not included during the bootstraping of the project nor was it added subsequently (check pom.xml file for it), then it can be added like this:
  
  [source, subs=attributes+]
  ----
   ./mvnw quarkus:add-extension -Dextensions="openshift"
  ----
  
  To trigger a build and deployment in a single step:
  
  [source, subs=attributes+]
  ----
  ./mvnw clean package -Dquarkus.kubernetes.deploy=true
  ----
  
  The aforementioned command will build a jar file locally, trigger a container image build and then apply the generated OpenShift resources.
  The generated resources are using OpenShift's `DeploymentConfig` that is configured to automatically trigger a redeployment when a change in the `ImageStream` is noticed.
  In other words, any container image build after the initial deployment will automatically trigger redeployment, without the need to delete, update or re-apply the generated resources.
  
  To confirm the above command has created an image stream, a service resource and has deployed the application (has a pod running), apply these commands:
  
  [source, subs=attributes+]
  ----
  oc get is
  oc get pods
  oc get svc
  ----
  
  To expose the created service to a route and test it:
  
  [source, subs=attributes+]
  ----
  oc expose svc/greeting
  oc get routes
  curl http://<route>/greeting
  ----
  
  === Customizing
  
  