$ oc start-build <buildconfig_name>
Manually start a new build from an existing build configuration in your current project using the following command:
$ oc start-build <buildconfig_name>
Re-run a build using the --from-build
flag:
$ oc start-build --from-build=<build_name>
Specify the --follow
flag to stream the build’s logs in stdout:
$ oc start-build <buildconfig_name> --follow
Specify the --env
flag to set any desired environment variable for the build:
$ oc start-build <buildconfig_name> --env=<key>=<value>
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. |
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
Manually cancel a build using the web console, or with the following CLI command:
$ oc cancel-build <build_name>
Cancel multiple builds at the same time:
$ oc cancel-build <build1_name> <build2_name> <build3_name>
Cancel all builds created from the build configuration:
$ oc cancel-build bc/<buildconfig_name>
Cancel all builds in a given state (for example, new or pending), ignoring the builds in other states:
$ oc cancel-build bc/<buildconfig_name> --state=<state>
Delete a BuildConfig
using the following command:
$ oc delete bc <BuildConfigName>
This will also delete 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>
You can view build details with the web console or by using the oc describe
CLI command:
$ oc describe build <build_name>
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.
You can access build logs using the web console or the CLI.
To stream the logs using the build directly:
$ oc logs -f build/<build_name>
To stream the logs of the latest build for a build configuration:
$ oc logs -f bc/<buildconfig_name>
To return the logs of a given version build for a build configuration:
$ oc logs --version=<number> bc/<buildconfig_name>
Log Verbosity
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. |
A platform administrator can set the default build verbosity for the entire OpenShift Origin
instance by configuring env/BUILD_LOGLEVEL for the BuildDefaults admission controller. 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. |