Project is the highest level entity, which separates things from other
A project can contain multiple
Branch can represent a real source code
repository branch of a
project, but it does not have to.
Branches are usually used to model
multiple parallel, often independent, activity streams of a
project. For example a customer-focused maintenance release
or a future-oriented development work.
Branches may have different views of the source code repository,
use different sets of tools, have different scopes of tests, etc.
branch can contain multiple
stage is used to define the detailed activities that will happen when a
stage is executed.
Stages can be linked together to make one
stage run after another
stage is completed.
stages that are not dependent (linked) and are ready to run, can be executed in parallel.
What is happening in a
stage is defined by
workflow schema or just
schema there can be defines:
- one or more
Stage linking is defined by parents property in a
Parameters can be used to differentiate and parametrize
their values can be provided by user while starting a
stage manually otherwise default values are used.
Configs allow for defining set of key-value pairs that statically define set of tests variants for execution.
Notifications can be used to inform users about
stage result. There are several media available like email or Slack.
Timeout limits the time of whole
stage executions. These assure us that the
stage will be terminated if something really
bad is happening in
jobs execution (e.g. they are hanging the machines).
More details about these
schema properties are available in chapter Schema.
Jobs describe what should be done in a
stage can define multiple
jobs and they all are run in parallel.
job contains one or more
steps that describe operations to be run sequentially. A single
step can be for example:
- execution of a shell command
- checking out sources from a repository
- running tests by a test tool
- running static checks by a linter
- and many more
Job contains definition of multiple
environment specifies the following conditions for the execution of a
- agents group - pointing to machines with agents which will be used to run the steps
- operating system - OS that will be used on the machines
- configuration - one of
configurationsdefined in the
With the help of
environments, the same
job can be run on various combinations of target machines, operating systems and configuration parameters.
So environments allow for running the same job:
- on several different operating system;
- on several different hardware, e.g.: one with AMD CPU, another one with Intel CPU;
- with different tests configurations, e.g.: running the same benchmark but in several different resolutions.
When Kraken triggers execution of stages, it starts a
flow begins with the first
stage (or group of
stages) in the
stage that has been triggered and is executing, is called a
runs are triggered by one of prior
Runs can also be triggered manually.
There can be two kinds of flows that are predefined by Kraken (see Kraken's Philosophy):
DEV flow- it represents pre-commit activities, for example it can be triggered by developer on demand
CI flow- it represents post-commit activities, for example it can be triggered by commits to the production source code (master)
run can dynamically determine in the context of which
flow it is running -
job that is being executed as part of a
run is called
run. It has an individual execution status. Upon completion, it can
also have multiple test results or issues.
step that is being executed as part of a
job in run is called
step in run.
job in run is executed (multiplied) for each of the
environments defined in a
Stage is defined in Python-like syntax.