Pipeline Syntax
Microtica provides a built-in support for defining and executing pipelines. The pipeline is defined using YAML syntax which allows creating pipelines in a declarative way.
The pipeline can be defined directly in the microtica.yaml definition file placed in your source code root dir.
The following is a skeleton of Microtica pipeline syntax:
- runtime (optional) – the runtime configuration for the pipeline
- computeType – runtime environment compute type
- stages (optional) – a list of stage names. Each stage can be assigned to one or multiple steps
- steps – a dictionary of steps
The following is a very simple pipeline definition:
This pipeline consists of two steps:
- Clone – clones the source code from the Git repository
- BuildAndTest – install node modules and compile the NodeJS source code
- PushDockerImage – build and push Docker image to a specified registry
Each pipeline step runs in a separate runtime environment to ensure security and isolation of the step execution.
Microtica allows you to set the compute type of the runtime environment on pipeline and individual step level.
Compute type corresponds to the amount of CPU and memory to be allocated for the pipeline.
To configure the compute type on pipeline level see the example below:
If you want to configure the compute type on a step level and override the pipeline configuration then see the example below:
With this configuration Test step will use the default compute environment of type SMALL but the Build step will use the compute environment of type MEDIUM.
To optimize the price and the performance of your pipeline executions, use compute types appropriate for the operations you are performing in the steps.
Use SMALL type for steps that don’t require high performance and use MEDIUM and LARGE types for steps that require more compute and memory intensive operations.
Steps are executed in serial in the order they are defined in the pipeline definition.
Here is an example of pipeline with multiple steps:
Pipeline starts by executing Clone step then BuildMyApp step, when this step finishes successfully with its execution, TestMyApp step is triggered for execution. Following the same logic, GenerateTestReports will execute when TestMyApp step completes successfully.
