The workflow is the main entity in CDS. It allows you to chain jobs, using conditional branching.
A workflow is described directly on your repository inside the directory .cds/workflows/
.
The permission manage-workflow
on your project is mandatory to manage a workflow.
name: cds
repository:
vcs: github
name: ovh/cds
commit-status:
...
on: [push]
integrations: [my-artifactory]
stages:
...
jobs:
...
env:
VAR_1: value
VAR_2: value2
gates:
...
name
: The name of your workflowon
: Allow you to define hooks to trigger your workflowjobs
: Jobs definitionsintegrations
: Integrations linked to the workflowrepository
: The repository linked to the workflowcommit-status
: Commit status created by CDS on workflow runstages
: List of stagesenv
: Define environment variable for the whole workflowgates
: Manual gate for your workflow* mandatory fields
The repository linked to you workflow allows you to:
on
checkout
that simply git clone actionA commit build status is always sent by CDS with default values. You can customize the title and description of the build status with the commit-status
attribute.
commit-status:
title: foo
description: bar
Available hooks:
push
: trigger the workflow on repository push eventpull-request
: trigger the workflow on repository pull-request event, see types of pull-request below.model-update
: trigger the workflow is a worker model used in the worker has been updatedworkflow-update
: trigger the workflow is the workflow definition was updatedmodel-update
and workflow-update
are only available is the workflow definition is different from the repository
field of your workflow. The hook will be triggered when default branch is updated, and will trigger the default branch of the destination repository
the on
field has 2 formats
on: [push,pull-request,model-update,workflow-update]
on:
push:
branches: [main,develop]
paths: [^src/.*/.*.java$]
model-update:
models: [MYPROJ/github/ovh/resources/mymodel]
target_branch: main
pull-request:
comment: "a comment here"
types: ["opened","reopened","closed","edited"]
branches: [main,develop]
paths: [^src/.*/.*.java$]
pull-request-comment:
comment: "a comment here"
types: ["created","deleted","edited"]
branches: [main,develop]
paths: [^src/.*/.*.java$]
workflow-update:
target_branch: main
push.branches
: branches filterpush.paths
: file paths filterpull-request.comment
: comment written by cds at workflow end if it was triggered by a pull-request event.pull-request.types
: types of pull-request event that can trigger the workflow. Could be: opened
, reopened
, closed
, edited
.pull-request.branches
: branches filterpull-request.paths
: file paths filterpull-request-comment.comment
: comment written by cds at workflow end if it was triggered by a pull-request-comment event.pull-request-comment.types
: types of pull-request-comment event that can trigger the workflow. Could be: created
, deleted
, edited
.pull-request-comment.branches
: branches filterpull-request-comment.paths
: file paths filtermodel-update.models
: worker model filtermodel-update.target_branch
: destination repository branch to triggerworkflow-update.target_branch
: destination repository branch to triggerAllow a job to use an project integration.
Integration can be put directly on a job or at the workflow top level to be applied on all jobs
Supported integrations:
Jobs field is a map that contains all the jobs of your workflow. The key of the map is the name that will be display in CDS UI
jobs:
myJob:
runs-on: ./cds/worker-models/my-custom-ubuntu.yml
vars: [varset1, varset2]
integrations: [my-artifactory]
steps:
run: echo 'Hello World'
mySecondJob:
runs-on: ./cds/worker-models/my-custom-ubuntu.yml
needs: [myJob]
steps:
run: echo 'Bye'
runs-on
: define on which worker model your job will be executedsteps
: the list of step to executename
: job descriptionneeds
: the list of jobs that need to be executed before this onevars
: the list of variable set available in the jobintegrations
: integration linked to the jobregion
: the region on which the job must be triggeredif
: condition that must be satisfied to run the job. if
and gate
field cannot be set togethergate
: manual gate definition to use.if
and gate
field cannot be set togetherinputs
: input of the job. If used, only these inputs can be used in the job steps. All others contexts cannot be usedstage
: link the job to a stagecontinue-on-error
: if true
, the job will be considered as Success when it failsintegrations
: link project integrations to your job. Available integration: artifactory
strategy
: add a run strategyservices
: add container services to run with your job.env
: define environment variables to inject to your job. It overrides environment variable with the same name defined at the workflow levelA step represent
jobs:
myjob:
steps:
- id: stepIdentifier
run: echo 'Hello World' # cannot be used with `uses`
uses: actions/checkout # cannot be used with `run`
with:
ref: develop
sha: aefd1235
if: failure()
continue-on-error: true
env:
NEW_VAR: myValue
id
: step identifierrun
: script to execute. Cannot be used simultaneously with uses
fielduses
: action to execute. Cannot be used simultaneously with run
fieldwith
: allow you to customize action input. Must be used with uses
fieldif
: condition that must be satisfied to execute the stepcontinue-on-error
: if true
, the step will be considered as Success when it failsenv
: define environment variables to inject to your job. It overrides environment variable with the same name defined oat the workflow and job levelInputs allow you to define a list of variable that will be used in your job. If you use it all others contexts will be unavailable. This allows you to exactly control the inputs of your job
jobs:
myjob:
inputs:
inp1: ${{ git.ref }}
inp2: ${{ cds.workflow }}
inp3: My Value
Allow you to define a execution strategy for your job.
Available strategy:
jobs:
myjob:
strategy:
matrix:
version: ["go1.21", go1.22]
os: [ubuntu, debian]
steps:
run: echo ${{ matrix.version }} - ${{ matrix.os }}
The matrix strategy allows you to template a job with matrix variables that will automatically create multiple jobs during the execution
In this example, CDS will create 4 jobs during execution with the given matrix context:
Service are docker containers spawned with your job in a private network. For example it allows you to start a postreSQL DB for your tests
jobs:
init:
runs-on: .cds/worker-models/buildpack-deps-buster.yml
services:
myngnix:
image: nginx:1.13
env:
NGINX_PORT: 80
readiness:
command: curl --fail http://myngnix:80
interval: 10s
timeout: 5s
retries: 5
mypostgres:
...
image
: The docker image of the serviceenv
: Environment variable to inject in the servicereadiness
: Allows you to configure a readiness test for your service. Your job will wait for it before starting the steps execution
command
: Command to execute to check the readiness of the serviceinterval
: Interval between 2 teststimeout
: Command timeout before failingretries
: Number of retriesGates are hooks that allow you to manually trigger a job under certain conditions
gates:
first-gate:
if: ${{ git.ref == 'main' && gate.approve }}
inputs:
approve:
type: boolean
reviewers:
groups: [release-team]
jobs:
myGateJob:
gate: first-gate
if
: condition that must be satisfied to pass the gateinputs
:
type
: type of the input (boolean, number, text)reviewers
: Allow you to define who can trigger the gate
groups
: list of groups that are allowed to trigger the gateusers
: list of users that are allowed to trigger the gateThe use of stages allows you to structure and organize jobs in a modular way
stages:
my-stage:
my-stage2:
needs: [my-stage]
needs
: the list of stages that need to be executed before this oneCondition can be use at different level but share the same syntaxe
You can use all contexts to create your condition
if: ${{ git.ref == "master" && cds.job == "MyJob" }}
or
if: git.ref == "master" && cds.job == "MyJob"
==
!=
>
<
>=
<=
||
&&
!