Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 24. Configuring Global Build Defaults and Overrides

24.1. Overview
Copy link

Developers can define settings in specific build configurations within their projects, such as configuring a proxy for Git cloning. Rather than requiring developers to define certain settings in each of their build configurations, cluster administrators can use admission control plug-ins to configure global build defaults and overrides that automatically use these settings in any build.

The settings from these plug-ins are not set in the build configurations or builds themselves, but rather are only used during the build process. This allows administrators to change the global configuration at any time, and any builds that are re-run from existing build configurations or builds will get the new settings.

  • The BuildDefaults admission control plug-in allows administrators to set global defaults for settings such as the Git HTTP and HTTPS proxy, as well as default environment variables. These defaults do not overwrite values that have been configured for a specific build. However, if those values are not present on the build definition, they are set to the default value.

  • The BuildOverrides admission control plug-in allows administrators to override a setting in a build, regardless of the value stored in the build. It currently supports overriding the forcePull flag on a build strategy to enforce always refreshing the local image during a build by pulling the image from the registry. This ensures that a user can only build with an image that they are allowed to pull. The plug-in can also be configured to apply a set of image labels to every built image.

    Note

    You can define a hard limit on how long build pods can run by using the RunOnceDuration plugin.

24.2. Setting Global Build Defaults
Copy link

You can set global build defaults two ways:

During advanced installations, the BuildDefaults plug-in can be configured using the following parameters, which are configurable in the inventory file:

  • openshift_builddefaults_http_proxy
  • openshift_builddefaults_https_proxy
  • openshift_builddefaults_no_proxy
  • openshift_builddefaults_git_http_proxy
  • openshift_builddefaults_git_https_proxy

Example 24.1. Example Build Defaults Configuration with Ansible

# These options configure the BuildDefaults admission controller which injects
# environment variables into Builds. These values will default to the global proxy
# config values. You only need to set these if they differ from the global settings
# above. See BuildDefaults
# documentation at https://docs.okd.io/latest/admin_guide/build_defaults_overrides.html
#openshift_builddefaults_http_proxy=http://USER:PASSWORD@HOST:PORT
openshift_builddefaults_https_proxy=https://USER:PASSWORD@HOST:PORT
openshift_builddefaults_no_proxy=build_defaults
openshift_builddefaults_git_http_proxy=http://USER:PASSWORD@HOST:PORT
openshift_builddefaults_git_https_proxy=https://USER:PASSWORD@HOST:PORT
# Or you may optionally define your own serialized as json
#openshift_builddefaults_json='{"BuildDefaults":{"configuration":{"apiVersion":"v1","env":[{"name":"HTTP_PROXY","value":"http://proxy.example.com.redhat.com:3128"},{"name":"NO_PROXY","value":"ose3-master.example.com"}],"gitHTTPProxy":"http://proxy.example.com:3128","kind":"BuildDefaultsConfig"}}}'
Copy to Clipboard Toggle word wrap
Note

There are additional proxy settings that can be configured for builds using Ansible parameters. For example: - The openshift_builddefaults_git_http_proxy and openshift_builddefaults_git_https_proxy parameters allow you to use a proxy for git cloning - The openshift_builddefaults_http_proxy and openshift_builddefaults_https_proxy parameters can make environment variables available to the Docker build strategy and Custom build strategy processes.

24.2.2. Manually Setting Global Build Defaults
Copy link

To configure the BuildDefaults plug-in, add a configuration for it in the /etc/origin/master/master-config.yaml file on masters: 

admissionConfig:
  pluginConfig:
    BuildDefaults:
      configuration:
        apiVersion: v1
        kind: BuildDefaultsConfig
        gitHTTPProxy: http://my.proxy:8080
1 

        gitHTTPSProxy: https://my.proxy:8443
2 

        gitNoProxy: somedomain.com, otherdomain.com
3 

        env:
        - name: HTTP_PROXY
4 

          value: http://my.proxy:8080
        - name: HTTPS_PROXY
5 

          value: https://my.proxy:8443
        - name: BUILD_LOGLEVEL
6 

          value: 4
        - name: CUSTOM_VAR
7 

          value: custom_value
        imageLabels:
        - name: url
8 

          value: https://containers.example.org
        - name: vendor
          value: ExampleCorp Ltd.
        nodeSelector:
9 

          key1: value1
          key2: value2
        annotations:
10 

          key1: value1
          key2: value2
        resources:
11 

          requests:
            cpu: "100m"
            memory: "256Mi"
          limits:
            cpu: "100m"
            memory: "256Mi"
Copy to Clipboard Toggle word wrap
1
Sets the HTTP proxy to use when cloning source code from a Git repository.
2
Sets the HTTPS proxy to use when cloning source code from a Git repository.
3
Sets the list of domains for which proxying should not be performed.
4
Default environment variable that sets the HTTP proxy to use during the build. This can be used for downloading dependencies during the assemble and build phases.
5
Default environment variable that sets the HTTPS proxy to use during the build. This can be used for downloading dependencies during the assemble and build phases.
6
Default environment variable that sets the build log level during the build.
7
Additional default environment variable that will be added to every build.
8
Labels to be applied to every image built. These can be overridden in BuildConfig.
9
Build pods will only run on nodes with the key1=value2 and key2=value2 labels. Users can define a different set of nodeSelectors for their builds, causing these values to be ignored.
10
Build pods will have these annotations added to them.
11
Sets the default resources to the build pod if the BuildConfig does not have related resource defined.

Restart the master service for the changes to take effect: 

# systemctl restart atomic-openshift-master
Copy to Clipboard Toggle word wrap

24.3. Setting Global Build Overrides
Copy link

To configure the BuildOverrides plug-in, add a configuration for it in the /etc/origin/master/master-config.yaml file on masters: 

admissionConfig:
  pluginConfig:
    BuildOverrides:
      configuration:
        apiVersion: v1
        kind: BuildOverridesConfig
        forcePull: true
1 

        imageLabels:
        - name: distribution-scope
2 

          value: private
        nodeSelector:
3 

          key1: value1
          key2: value2
        annotations:
4 

          key1: value1
          key2: value2
Copy to Clipboard Toggle word wrap
1
Force all builds to pull their builder image and any source images before starting the build.
2
Additional labels to be applied to every image built. Labels defined here take precedence over labels defined in BuildConfig.
3
Build pods will only run on nodes with the key1=value2 and key2=value2 labels. Users can define additional key/value labels to further constrain the set of nodes a build runs on, but the node must have at least these labels.
4
Build pods will have these annotations added to them.

Restart the master service for the changes to take effect: 

# systemctl restart atomic-openshift-master
Copy to Clipboard Toggle word wrap
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat