Creating a Separate Build & Triggering a New Build

 When the Source build strategy is invoked by oc new-app, it sets up two steps. The first step is to run the build using S2I, combining the source files with the builder image to create the runnable image. The second step is to deploy the runnable image and start up the web application.


You can perform the build step separately by running the oc new-build command instead of the oc new-app command: 

$ oc new-build --name blog \ python:3.5~https://github.com/openshift-katacoda/blog-django-py

The output looks similar, but the deploymentconfig and service resource objects are not created. When the build has completed, the runnable image created is saved away as the image stream called blog. To deploy that image, the oc new-app command is used, but this time the name of the imagestream created by the build is supplied instead of the details of the builder image and repository URL:

$ oc new-app blog 

Triggering a New Build


In the event that the source files used as input to the Source build strategy have changed, a new build can be triggered using the oc start-build command: 
$ oc get bc 
NAME       TYPE     FROM    LATEST 
blog           Source             Git           1 
$ oc start-build bc/blog
build "blog-2" started 


Even though you created the build separately from setting up the deployment, when the build has completed and the imagestream updated, a redeployment will be auto‐ matically triggered. This occurs because oc new-app automatically sets up an image change trigger in the deployment configuration. Triggers are also defined as part of the build configuration. The first of these is an additional image change trigger. This trigger will result in a rebuild if the S2I builder image python:3.5 is updated. This is an important feature of the build process

Building from a Local Source 
The build configuration that was set up used source files held in a hosted source code repository. To rebuild your application, your code changes had to be pushed up to the repository. Although the build is linked to the hosted source code repository, one-off builds can bypass the repository and use source files from a local filesystem. Building from a local source is triggered using oc start-build, with the location of the local source directory specified using the --from-dir option: 
$ oc start-build bc/blog --from-dir=.

To revert to using source files held in the hosted code repository, start a new build without specifying an input source for the files:
 $ oc start-build bc/blog

Binary Input Builds

The variation on a build used to run a single build from a local source is called a binary input source build. This is useful during the development of an application, as you can iterate on changes without needing to commit and push changes up to the repository. You only commit and push up changes when you have checked the result and are finished. A build configuration can be set up from the outset as a binary input source build. In this configuration it would not be linked to a hosted source code repository, and all builds would need to be triggered manually and the source files supplied. To create a binary input build configuration, use oc new-build and supply the --binary option:
 $ oc new-build --name blog --binary --strategy=source --image-stream python:3.5

The initial and subsequent builds are triggered using oc start-build, supplying the --from-dir option to use source files from a local directory: 
$ oc start-build blog --from-dir=.
 Uploading directory "." as binary input for the build ...
 build "blog-1" started 

Because the build configuration isn’t linked to a source code repository and oc start-build must be manually run each time, applications cannot be automatically rebuilt and redeployed if an S2I builder image has changed. This is because the input source would not be available to the build.


'' failed to upload. Invalid response: Unexpected token < in JSON at position 0


Comments

Popular posts from this blog

Read and Navigate XML - Beautiful Soup

difference-between-stream-processing-and-message-processing

WordNet in Python