Profiles
Profiles allow to specify different values of environment variables, arguments, steps and volumes when the specific profile is activated.
For example, the behavior of the build may change depending on the host system or the type of CI, e.g. it may publish artifacts into different repositories if the build is executed in a compliant CI environment or a non-compliant one.
schemaVersion: 1.8.0
version: 1.0
default:
build:
args:
namespace: dev
dockerImages:
- dockerFile: Dockerfile
tags:
- docker.simple-container.com/${arg:namespace}/service:${project:version}
profiles:
sox:
activation:
sox: true
build:
args:
namespace: sox
modules:
- name: microservice
In the example above, whenever the profile sox is activated, the namespace argument will be set to sox and the
built Docker image will be prefixed with the sox namespace. By default, it would have dev namespace.
Modes
Welder introduces a few modes that conditionally can activate profiles or can be used within expressions. Each
mode is activated by either passing a flag to welder command or implicitly derived from host environment
build is running on.
Each mode can either activate a certain profile or be used from an expression to conditionally run a task.
There are the following flags:
* --sox activates "sox" mode which can be used to change configuration of the build
* --skip-tests activates "skip-tests" mode which can be used to skip certain tasks considered to be tests
* --on-host activates "on-host" mode which forces all steps and tasks to run on host environment instead of a Docker container
* --verbose activates "verbose" mode that produces debug messages from Welder
* --no-cache activates "no-cache" mode which disables caching of the built Docker images and forces them to be rebuilt every time
* --sync-mode=<value> activates one of the supported volume synchronization modes
Modes derived from environment are:
* bamboo activated whenever build is running on Bamboo
* pipelines activated when build is running on Bitbucket Pipelines
Inheritance
All build configuration properties, including args, env, volumes and steps can be inherited from either default
config, profile or module configuration.
The inheritance of the values will be done in the following order: default, profile, module, task. That is
task definitions has the highest priority and overrides all other configurations, whereas default has the lowest.