Skip to main content

Basic CI configuration

Metroline expects your CI configuration inside a .metroline.yml file placed at the root of your projects.

A basic example looks like this:

version: '1'
jobs:
# our build job
build:
# docker image of this job
image: node:12
# a set of commands to execute in a node:12 container
script:
- npm ci
- npm run build
# a job named "test"
test:
image: node:12
script:
- npm test

Job name clone is reserved.

Global image

Instead of defining an image for each job, you can define a global one:

version: '1'
image: node:12
jobs:
build:
script:
- npm run build
test:
script:
- npm run test

You must specify a job image if you haven't defined a global image

bin

By default, all jobs use the /bin/sh executable, but you are free to change it with the bin job property:

version: '1'
image: node:12
jobs:
build:
bin: /bin/bash # or simply "bash"
script:
- npm run build

This can be any valid executable available in the shell. In the above example, we could have set bin to bash, because bash is available globally in the node:12 Docker image.

dependencies

By default, all jobs are executed in parallel. To model dependencies between your jobs, you can use the dependencies job property:

You cannot defined cyclic dependencies.

version: '1'
image: node:12
jobs:
build:
script:
- npm run build
test:
script:
- npm run test
dependencies:
- build

In the above example, job test will be executed only when job build has succeeded.

This might sound a bit verbose, but it allows you to create complex workflows:

version: '1'
image: node:12
jobs:
build:
script:
- npm run build
test-node-11:
image: node:11
script:
- npm run test
dependencies:
- build
test-node-12:
script:
- npm run test
dependencies:
- build
publish:
script:
- npm publish
dependencies:
- test-node-11
- test-node-12

Job publish will only be executed when jobs test-node-11 and test-node-12 have succeeded.

Metroline shares the same workspace between jobs, you are responsible for making sure parallel jobs do not conflict using the filesystem.

allowFailure

Sometimes, you don't want your entire pipeline to stop because a not-so-important job failed. You can use the allowFailure job property for this purpose:

 version: '1'
image: node:12
jobs:
build:
script:
- npm run build
test-node-11:
image: node:11
allowFailure: true
script:
- npm run test
dependencies:
- build
test-node-12:
script:
- npm run test
dependencies:
- build
publish:
script:
- npm publish
dependencies:
- test-node-11
- test-node-12

If job test-node-11 fails, job publish will still be executed.