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.
Comments
Post a Comment