Chapter 7. Performing basic builds
The following sections provide instructions for basic build operations including starting and canceling builds, deleting BuildConfigs, viewing build details, and accessing build logs.
7.1. Starting a build
You can manually start a new build from an existing build configuration in your current project.
Procedure
To manually start a build, run:
$ oc start-build <buildconfig_name>
7.1.1. Re-running a build
You can manually re-run a build using the --from-build flag.
Procedure
To manually re-run a build, run:
$ oc start-build --from-build=<build_name>
7.1.2. Streaming build logs
You can specify the --follow flag to stream the build’s logs in stdout.
Procedure
To manually stream a build’s logs in stdout, run:
$ oc start-build <buildconfig_name> --follow
7.1.3. Setting environment variables when starting a build
You can specify the --env flag to set any desired environment variable for the build.
Procedure
To specify a desired environment variable, run:
$ oc start-build <buildconfig_name> --env=<key>=<value>
7.1.4. Starting a build with source
Rather than relying on a Git source pull or a Dockerfile for a build, you can can also start a build by directly pushing your source, which could be the contents of a Git or SVN working directory, a set of prebuilt binary artifacts you want to deploy, or a single file. This can be done by specifying one of the following options for the start-build command:
| Option | Description |
|---|---|
|
| Specifies a directory that will be archived and used as a binary input for the build. |
|
| Specifies a single file that will be the only file in the build source. The file is placed in the root of an empty directory with the same file name as the original file provided. |
|
|
Specifies a path to a local repository to use as the binary input for a build. Add the |
When passing any of these options directly to the build, the contents are streamed to the build and override the current build source settings.
Builds triggered from binary input will not preserve the source on the server, so rebuilds triggered by base image changes will use the source specified in the build configuration.
Procedure
For example, the following command sends the contents of a local Git repository as an archive from the tag v2 and starts a build:
$ oc start-build hello-world --from-repo=../hello-world --commit=v2
7.2. Canceling a build
You can cancel a build using the web console, or with the following CLI command.
Procedure
To manually cancel a build, run:
$ oc cancel-build <build_name>
7.2.1. Canceling multiple builds
You can cancel multiple builds with the following CLI command.
Procedure
To manually cancel multiple builds, run:
$ oc cancel-build <build1_name> <build2_name> <build3_name>
7.2.2. Canceling all builds
You can cancel all builds from the build configuration with the following CLI command.
Procedure
To cancel all builds, run:
$ oc cancel-build bc/<buildconfig_name>
7.2.3. Canceling all builds in a given state
You can cancel all builds in a given state (for example, new or pending), ignoring the builds in other states.
Procedure
To cancel all in a given state, run:
$ oc cancel-build bc/<buildconfig_name>
7.3. Deleting a BuildConfig
You can delete a BuildConfig using the following command.
Procedure
To delete a BuildConfig, run:
$ oc delete bc <BuildConfigName>
This also deletes all builds that were instantiated from this BuildConfig. Specify the --cascade=false flag if you do not want to delete the builds:
$ oc delete --cascade=false bc <BuildConfigName>
7.4. Viewing build details
You can view build details with the web console or by using the oc describe CLI command.
This displays information such as:
- The build source
- The build strategy
- The output destination
- Digest of the image in the destination registry
- How the build was created
If the build uses the Docker or Source strategy, the oc describe output also includes information about the source revision used for the build, including the commit ID, author, committer, and message.
Procedure
To view build details, run:
$ oc describe build <build_name>
7.5. Accessing build logs
You can access build logs using the web console or the CLI.
Procedure
To stream the logs using the build directly, run:
$ oc describe build <build_name>
7.5.1. Accessing BuildConfig logs
You can access BuildConfig logs using the web console or the CLI.
Procedure
To stream the logs of the latest build for a BuildConfig, run:
$ oc logs -f bc/<buildconfig_name>
7.5.2. Accessing BuildConfig logs for a given version build
You can access logs for a given version build for a BuildConfig using the web console or the CLI.
Procedure
To stream the logs for a given version build for a BuildConfig, run:
$ oc logs --version=<number> bc/<buildconfig_name>
7.5.3. Enabling log verbosity
You can enable a more verbose output by passing the BUILD_LOGLEVEL environment variable as part of the sourceStrategy or dockerStrategy in a BuildConfig.
An administrator can set the default build verbosity for the entire OpenShift Container Platform instance by configuring env/BUILD_LOGLEVEL. This default can be overridden by specifying BUILD_LOGLEVEL in a given BuildConfig. You can specify a higher priority override on the command line for non-binary builds by passing --build-loglevel to oc start-build.
Available log levels for Source builds are as follows:
| Level 0 | Produces output from containers running the assemble script and all encountered errors. This is the default. |
| Level 1 | Produces basic information about the executed process. |
| Level 2 | Produces very detailed information about the executed process. |
| Level 3 | Produces very detailed information about the executed process, and a listing of the archive contents. |
| Level 4 | Currently produces the same information as level 3. |
| Level 5 | Produces everything mentioned on previous levels and additionally provides docker push messages. |
Procedure
To enable more verbose output, pass the BUILD_LOGLEVEL environment variable as part of the sourceStrategy or dockerStrategy in a BuildConfig:
sourceStrategy:
...
env:
- name: "BUILD_LOGLEVEL"
value: "2" 1- 1
- Adjust this value to the desired log level.
