- Overview
- Properties
- version
- name
- agent
- execution_time_limit
- Blocks
- Task
- Jobs
- Prologue and Epilogue
- The secrets property
- promotions
- Complete examples
- The order of execution
- Comments
- See also
This document is the reference of the YAML grammar used for describing the pipelines of Semaphore 2.0 projects.
The core properties of a Semaphore 2.0 pipeline configuration file are
blocks, which appear only once at the beginning of a YAML file, task,
which can appear multiple times, jobs, which can also be repeated, and
promotions that is optional and can appear only once.
Moreover, each Semaphore 2.0 pipeline configuration file has a preface part,
which is mandatory and should be present on every Pipeline YAML file you
create. The properties of the preface part are version, name,
which is the only optional one, and agent.
The version property is a string value that shows the version of the
pipeline YAML file that will be used.
The list of valid values for version: v1.0.
Example of version usage:
version: v1.0
The name property is a Unicode string that assigns a name to a Semaphore
2.0 project and is optional. However, you should always give descriptive names
to your Semaphore 2.0 projects.
Note: The name property can be found in other sections for defining the
name of a job inside a jobs block or the name of a task section defined
using task.
Example of name usage:
name: The name of the Semaphore 2.0 project
The agent property requires one additional property named machine, that
identifies the environment, that is the hardware of the Virtual machine and the
Operating System of the Virtual Machine, in which the jobs of the pipeline will
get executed.
Example of agent usage:
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
Tip: The agent property can be also defined on a per task basis.
The machine property, which can only be defined under agent, requires two
properties named type and os_image.
Example of machine usage:
machine:
type: e1-standard-2
os_image: ubuntu1804
The type property is intended for selecting the machine (hardware) you would
like to use on the Virtual Machine of your builds.
You can learn about the list of valid values for the type property by visiting
the Machine Types page.
Example of type usage:
type: e1-standard-2
The e1-standard-2 value used in the type property represents a predefined
hardware of the Virtual Machine used for executing jobs in the current
pipeline.
The os_image property specifies the operating system and the version of the
operating system that will be used.
The list of valid values for os_image: ubuntu1804.
Example of os_image usage:
os_image: ubuntu1804
The ubuntu1804 value used in the os_image property represents the Operating
System of the Virtual Machine used for executing the jobs of the current
pipeline.
version: v1.0
name: The name of the Semaphore 2.0 project
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
- name: Inspect Linux environment
task:
jobs:
- name: Print Envrinment variable
commands:
- echo $SEMAPHORE_PIPELINE_ID
The concept behind the execution_time_limit property is simple: you do not
want your jobs to be executed for ever and you need to be able to set a time
limit for the entire pipeline as well as for individual blocks.
The execution_time_limit property can be used in two ways. First, with a
pipeline scope where you define the execution time limit for the entire
pipeline and second, with a block scope where you define the execution time
limit for a single block. In the latter case you can use the execution_time_limit
property in multiple blocks.
Please note that the pipeline time limit is time limit for the sum of the running times of all the blocks of the pipeline.
The execution_time_limit property can hold two other properties, which are
named hours and minutes, for specifying the execution time limit in hours,
and minutes, respectively. You should only use one of these two properties and
not both of them at the same time.
The types of the values for both the hours and minutes properties are
integers and their values should be greater than or equal to 1.
If the execution_time_limit property is not used at all, the default global
value of the execution_time_limit property is 1 hour. Additionally, if
a pipeline has only local execution_time_limit properties, the global value
of execution_time_limit will still be 1 hour.
The following pipeline YAML file uses an execution_time_limit property
with a pipeline scope:
version: v1.0
name: Using execution_time_limit
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
execution_time_limit:
hours: 3
blocks:
- name: Creating Docker Image
task:
jobs:
- name: Docker build
commands:
- checkout
- sleep 120
- name: Building executable
task:
jobs:
- name: Building job
commands:
- echo 360
- echo "Building executable"
The following pipeline YAML file uses two execution_time_limit properties in a block:
version: v1.0
name: Using execution_time_limit
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
- name: Creating Docker Image
execution_time_limit:
minutes: 15
task:
jobs:
- name: Docker build
commands:
- checkout
- sleep 120
- name: Building executable
execution_time_limit:
minutes: 10
task:
jobs:
- name: Building job
commands:
- echo 360
- echo "Building executable"
The following pipeline YAML file uses a combination of an execution_time_limit property
with a pipeline scope and a single execution_time_limit property with a block scope:
version: v1.0
name: Using execution_time_limit
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
execution_time_limit:
hours: 5
blocks:
- name: Creating Docker Image
execution_time_limit:
minutes: 15
task:
jobs:
- name: Docker build
commands:
- checkout
- sleep 120
- name: Building executable
task:
jobs:
- name: Building job
commands:
- checkout
- echo "Building executable"
In this case the Creating Docker Image block should finish in less than 15
minutes whereas the Building executable block should finish in less than 5
hours, which is the value of the pipeline scope execution_time_limit property.
However, as blocks are currently executed sequentially, the
Building executable block should finish in 5 hours minus the time it took the
Creating Docker Image block to finish.
The blocks property defines an array of items that hold the elements of a
pipeline. Each element of that array is called a block and can have two
properties: name, which is optional and task, which is compulsory.
The name property is a Unicode string that assigns a name to a block and is
optional.
If you accidentally name two or more blocks items with the same name value,
you will get an error message similar to the following:
semaphore.yml ERROR:
Error: "There are at least two blocks with same name: Build Go project"
Semaphore assigns its own unique names to nameless blocks items, which are
displayed in the Semaphore 2.0 UI.
All the items of a blocks list have a task property that at the current
moment is required.
You will learn about the properties of a task item in a while.
version: v1.0
name: The name of the Semaphore 2.0 project
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
- name: Inspect Linux environment
task:
jobs:
- name: Print Environment variables
commands:
- echo $SEMAPHORE_PIPELINE_ID
- echo $HOME
The task property that is a compulsory part of each block of a blocks
property divides a YAML configuration file into major and distinct sections.
Each task item can have multiple jobs items, an optional agent section,
an optional prologue section, an optional epilogue section as well as an
optional env_vars block for defining environment variables and an optional
secrets block for using predefined environment variables from predefined
secrets.
A jobs item is a property of task that allows you to define the commands
that you want to execute.
The agent section under a task section is optional and can coexist with the
global agent definition at the beginning of a Pipeline YAML file. The
properties and the possible values of the agent section can be found in the
agent reference.
An agent block under a task block overrides the global agent definition.
The secrets property is used for using existing environment variables from
a secret. This is described in the The secrets property
section.
A prologue block is executed before the commands of each job of a task
item.
You can consider the prologue commands as a part of each one of the jobs of
the same task item.
An epilogue block is executed after the commands of each jobs item of a
task.
The elements of an env_vars array are name and value pairs that hold the name
of the environment variable and the value of the environment variable,
respectively.
version: v1.0
name: A Semaphore 2.0 project
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
task:
jobs:
- name: Check environment variables
commands:
- echo $HOME
- echo $PI
- echo $VAR1
env_vars:
- name: PI
value: "3.14159"
- name: VAR1
value: This is Var 1
The preceding pipeline YAML file defines two environment variables named VAR1
and PI. Both environment variables have string values, which means that
numeric values that are not natural numbers need to be included in double
quotes.
version: v1.0
name: The name of the Semaphore 2.0 project
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
task:
jobs:
- name: Check environment variables
commands:
- echo $SEMAPHORE_PIPELINE_ID
- echo $HOME
- echo $PI
- pwd
prologue:
commands:
- checkout
env_vars:
- name: PI
value: "3.14159"
Caution: The indentation level of prologue, epilogue, env_vars and
jobs properties should be the same.
version: v1.0
name: YAML file example with task and agent.
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
- name: Inspect Linux environment
task:
jobs:
- name: Learn about SEMAPHORE_GIT_DIR
commands:
- echo $SEMAPHORE_GIT_DIR
- name: Agent in task
task:
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
jobs:
- name: Using agent job
commands:
- echo $PATH
The jobs items are essential for each pipeline because they allow you to
define the actual commands that you want to execute.
The value of the optional name property is a Unicode string that provides a
name to a job.
Semaphore assigns its own names to nameless jobs items, which is what is
displayed in the UI.
Tip: It is considered a good practice to give descriptive names to all the
jobs and the blocks items of a Semaphore 2.0 pipeline.
The commands property is an array of strings that holds the commands that
will be executed for a job.
The general structure of a job when using the commands property is as follows:
version: v1.0
name: The name of the Semaphore 2.0 project
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
task:
jobs:
- name: Check environment variables
commands:
- echo $SEMAPHORE_PIPELINE_ID
- pwd
The commands_file file property allows you to define the path of a plain text
file that contains the commands of a job that is an item in a jobs list, a
prologue or an epilogue block instead of listing them in a commands list.
You cannot use both commands_file and commands when defining a job, a
prologue or an epilogue item. Moreover, you cannot have a job, a prologue
or an epilogue properly defined if both the commands and commands_file
properties are missing.
The contents of the YAML file that defines the pipeline are as follows:
version: v1.0
name: Using commands_file
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
- name: Calling text file
task:
jobs:
- name: Using command_file
commands_file: file_with_commands
prologue:
commands:
- checkout
The contents of file_with_commands are as follows:
echo "Command File"
echo "Exit command_file"
Some information about what happens behind the scenes: Semaphore 2.0
reads the plain text file and creates the equivalent job using a
commands block, which is what is finally executed. This means that
the commands_file property is replaced before the job is started and a
machine begins its execution.
An env_vars block can also be defined within a jobs block having a local
scope in addition to an env_vars block that is defined on a task level
where its scope is the entire task block. In that case the environment
variables of that local env_vars block will be only visible to the jobs
block it belongs to.
If one or more environment variables are defined on both a jobs level and a
task level, the values of the environment variables that are defined on the
jobs level take precedence over the values of the environment variables that
were also defined on the task level.
version: v1.0
name: Using env_vars per jobs
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
- name: Using Local Environment variables only
task:
jobs:
- name: Job that uses local env_vars
commands:
- echo $APP_ENV
env_vars:
- name: APP_ENV
value: This is APP_ENV
- name: VAR_2
value: This is VAR_2 from First Job
- name: Both local end global env_vars
task:
env_vars:
- name: APP_ENV
value: prod
- name: VAR_1
value: VAR_1 from outer env_vars
jobs:
- name: Using both global and local env_vars
commands:
- echo $VAR_1
- echo $VAR_2
- echo $APP_ENV
env_vars:
- name: VAR_1
value: This is VAR_1
- name: VAR_2
value: This is VAR_2
- name: Second job - no local env_vars
commands:
- echo $VAR_1
- echo $APP_ENV
The martix property allows you to define one or more environment variable
sets with multiple values. In such a setup, n parallel jobs are created,
where n equals the cardinality of the Cartesian product of all environment
variable sets.
So, the final outcome of the matrix property is the creation of multiple
parallel jobs with exactly the same commands that are defined in the respective
commands property. Each generated job is assigned with the environment
variables from corresponding element of Cartesian product.
The following pipeline illustrates the use of the matrix property:
version: v1.0
name: Using the matrix property
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
- name: Elixir + Erlang
task:
jobs:
- name: Elixir + Erlang matrix
commands:
- echo $ELIXIR
- echo $ERLANG
matrix:
- env_var: ELIXIR
values: ["1.3", "1.4"]
- env_var: ERLANG
values: ["19", "20", "21"]
In this example, the job specification named Elixir + Erlang matrix expands
to 6 parallel jobs as there are 2 * 3 = 6 combinations of the provided
environment variables:
Elixir + Erlang matrix - ELIXIR=1.4, ERLANG=21Elixir + Erlang matrix - ELIXIR=1.4, ERLANG=20Elixir + Erlang matrix - ELIXIR=1.4, ERLANG=19Elixir + Erlang matrix - ELIXIR=1.3, ERLANG=21Elixir + Erlang matrix - ELIXIR=1.3, ERLANG=20Elixir + Erlang matrix - ELIXIR=1.3, ERLANG=19
Each task element can have a single prologue and a single epilogue
element. Both prologue and epilogue properties are optional.
A prologue block in a task block is used when you want to execute certain
commands prior to the commands of each job of that task. This is usually the
case with initialization commands that install software, start or stop
services, etc.
Please notice that a pipeline will fail if a command in a prologue block
fails to execute for some reason.
version: v1.0
name: YAML file illustrating the prologue property
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
- name: Display a file
task:
jobs:
- name: Display hw.go
commands:
- ls -al
- cat hw.go
prologue:
commands:
- checkout
An epilogue block should be used when you want to execute some commands after
a job has finished, either successfully or unsuccessfully.
Please notice that a pipeline will not fail if one or more commands in the
epilogue fail to execute for some reason.
version: v1.0
name: YAML file illustrating the epilogue property
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
- name: Linux version
task:
jobs:
- name: Execute uname
commands:
- uname -a
epilogue:
commands:
- df
A secret is a place for keeping sensitive information in the form of
environment variables and small files. Sharing sensitive data in a secret is
both safer and more flexible than storing it using plain text files or
environment variables that anyone can access. A secret is defined using a specific
YAML grammar
and processed using the sem command line tool.
The secrets property is used for importing all the environment variables
and files from an existing secret into a Semaphore 2.0 organization.
If one or more names of the environment variables from two or more imported secrets are the same, then the shared environment variables will have the value that was found in the secret that was imported last. The same rule applies to the files in secrets.
Additionally, if you try to use a name value that does not exist, the
pipeline will fail to execute.
The name property is compulsory is a secrets block because it specifies the
secret that you want to import. Please note that the specified secret or
secrets should exist under the active organization.
You can store one or more files in a secret.
You do not need any extra work for using a file that you stored in a secret
apart from including the name of the secret that holds the file in the
secrets list of the pipeline YAML file. After that the only other requirement is
remembering the name of the file, which is the value you put in the path
property when creating the secret.
All files in secrets are restored in the home directory of the user of the
Virtual Machine (VM), which is /home/semaphore.
version: v1.0
name: Pipeline configuration with secrets
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
- task:
jobs:
- name: Using secrets
commands:
- echo $USERNAME
- echo $PASSWORD
secrets:
- name: mysql-secrets
Environment variables imported from a secrets property are used like regular
environment variables defined in a env_vars block.
version: v1.0
name: Using files in secrets in Semaphore 2.0
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
- task:
jobs:
- name: file.txt
commands:
- checkout
- ls -l ~/file.txt
- cd ..
- cat file.txt
- echo $SECRET_ONE
secrets:
- name: more-secrets
- name: my-secrets
In this case the name of the file that was saved in a secret is file.txt
and is located at the home directory of the VM.
The promotions property is used for promoting (manually or automatically
triggering) one or more pipelines using one or more pipeline YAML files,
respectively. A pipeline YAML file can have a single promotions block or
no promotions block at all.
The items of a promotions block are called targets and are implemented using
pairs of name and pipeline_file properties. A promotions block can have
multiple targets.
You can promote a target from the UI at any point, even while the pipeline that owns that target is still running.
The name property in a promotions block is compulsory, defines the name of a
target and is a Unicode string.
The pipeline_file property of the promotions block, which is compulsory,
is a path to another pipeline YAML file within the GitHub repository of the
Semaphore project.
If the pipeline_file value is just a plain filename without any directories,
then pipeline_file will look for it inside the .semaphore directory.
Otherwise, it will follow the given path beginning from the .semaphore
directory.
Each pipeline_file value must be a valid and syntactically correct pipeline
YAML file as defined in this document. However, the potential errors of a
pipeline YAML file that is given as a value to the pipeline_file property
will be revealed when the relevant target is promoted.
The same will happen if the file given as a pipeline_file value does not
exist – the error will be revealed at the time of promotion.
The contents of the .semaphore/semaphore.yml are as follows:
version: v1.0
name: Using promotions
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
- name: ls
task:
jobs:
- name: List contents
commands:
- ls -al
- echo $SEMAPHORE_PIPELINE_ID
promotions:
- name: Pipeline 1
pipeline_file: p1.yml
- name: Pipeline 2
pipeline_file: p2.yml
The promotions block in the aforementioned .semaphore/semaphore.yml file
will allow you to promote two other YAML files named p1.yml and
p2.yml.
The contents of the .semaphore/p1.yml are as follows:
version: v1.0
name: This is Pipeline 1
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
- name: Environment variable
task:
jobs:
- name: SEMAPHORE_PIPELINE_ID
commands:
- echo $SEMAPHORE_PIPELINE_ID
Last, the contents of the .semaphore/p2.yml are as follows:
version: v1.0
name: This is Pipeline 2
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
- name: List VM Linux version
task:
jobs:
- name: uname
commands:
- echo $SEMAPHORE_PIPELINE_ID
- uname -a
The auto_promote_on property is used for automatically promoting one or more
branches of promotions blocks according to user specified rules.
The auto_promote_on property is a list of items and supports three
properties: result, which is mandatory, branch, which is optional, and
result_reason, which is also optional.
For a auto_promote_on branch to execute, the return values of all the used
properties of that branch must be true.
The value of the result property is a string that is used for matching the
status of a pipeline.
The list of valid values for result: passed, stopped, canceled and
failed.
passed: all the blocks in the pipeline ended successfullystopped: the pipeline was stopped either by the user or by the systemcanceled: the pipeline was cancelled either by the user or by the system. The difference betweencanceledandstoppedis that a pipeline that is not running can be cancelled but cannot be stopped.failed: the pipeline failed either due to a pipeline YAML syntax error or because at least one of the blocks of the pipeline failed due to a command not being successfully executed.
The branch property is a list of items. Its items are regular expressions
that Semaphore 2.0 tries to match against the name of the GitHub branch that
is used with the pipeline that is being executed. If any of them is a match,
then the return value of the branch is true.
The branch property uses Perl Compatible Regular Expressions.
In order for a branch value to match the master branch only and not match
names such as this-is-not-master or a-master-alternative, you should use
^master$ as the value of the branch property. The same rule applies for
matching words or strings.
In order for a branch value to match branches that begin with dev you
should try something like ^dev.
The value of the result_reason property is a string that signifies the reason
that the value of the result property happened.
The list of valid values for result_reason: test, malformed, stuck,
deleted, internal and user.
test: one or more of user tests failedmalformed: the pipeline YAML file is not correctstuck: the pipeline was stuck for some internal reason and then aborteddeleted: the pipeline was terminated because the GitHub branch was deleted while the pipeline was runninginternal: the pipeline was terminated for internal reasonsuser: the pipeline was stopped on user request
Not all result and result_reason combinations make sense. For example, you
cannot have passed as the value of result and malformed as the value of
result_reason. On the other hand, you can have failed as the value of
result and malformed as the value of result_reason.
For a result value of failed, the valid values of result_reason are
test, malformed and stuck. When the result value is stopped or
canceled, the list of valid values for result_reason are deleted,
internal and user.
The following pipeline YAML file presents an example use of auto_promote_on
and depends on two other pipeline YAML files named p1.yml and p2.yml:
version: v1.0
name: Testing Auto Promoting
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
promotions:
- name: Staging
pipeline_file: p1.yml
auto_promote_on:
- result: passed
branch:
- "master"
- result: failed
branch:
- "v2."
result_reason: malformed
- name: prod
pipeline_file: p2.yml
blocks:
- name: Block 1
task:
jobs:
- name: Job 1 - Block 1
commands:
- echo $SEMAPHORE_GIT_BRANCH
- name: Job 2 - Block 1
commands:
- echo Job 2 - Block 1
- name: Block 2
task:
jobs:
- name: Job 1 - Block 2
commands:
- echo Job 1 - Block 2
- echo $SEMAPHORE_GIT_BRANCH
- name: Job 2 - Block 2
commands:
- echo Job 2 - Block 2
According to the specified rules only the Staging promotion of the promotions
list can be auto promoted – this depends on the rules of the two items of
the auto_promote_on list. However, the prod promotion of the promotions
list has no auto_promote_on property so there is no way it can be auto
promoted.
So, if the pipeline finishes with result passed and the GitHub branch name
contains the word master in its name then the p1.yml pipeline file will be
auto promoted. The same will happen if the the pipeline finishes with result
failed, the result_reason is malformed and the GitHub branch name
contains the v2 sequence of characters followed by at least one more
character because a . character in a Perl Compatible Regular Expression means
one or more characters.
The contents of p1.yml are as follows:
version: v1.0
name: Pipeline 1
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
- name: Environment variable
task:
jobs:
- name: SEMAPHORE_PIPELINE_ID
commands:
- echo $SEMAPHORE_PIPELINE_ID
The contents of p2.yml are the following:
version: v1.0
name: This is Pipeline 2
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
- name: List VM Linux version
task:
jobs:
- name: uname
commands:
- echo $SEMAPHORE_PIPELINE_ID
- uname -a
Both p1.yml and p2.yml are perfectly correct pipeline YAML files that could
have been used as semaphore.yml files.
The following code presents a complete .semaphore/semaphore.yml file:
version: v1.0
name: YAML file example for Go project
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
- name: Inspect Linux environment
task:
jobs:
- name: Execute hw.go
commands:
- echo $SEMAPHORE_PIPELINE_ID
- echo $HOME
- echo $SEMAPHORE_GIT_DIR
- echo $PI
prologue:
commands:
- checkout
env_vars:
- name: PI
value: "3.14159"
- name: Build Go project
task:
jobs:
- name: Build hw.go
commands:
- checkout
- change-go-version 1.10
- go build hw.go
- ./hw
- name: PATH variable
commands:
- echo $PATH
epilogue:
commands:
- echo $SEMAPHORE_JOB_RESULT
- echo $SEMAPHORE_PIPELINE_ID
version: v1.0
name: Pipeline configuration with secrets
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
- task:
jobs:
- name: Using secrets
commands:
- checkout
- ls -l .semaphore
- echo $SEMAPHORE_PIPELINE_ID
- echo $SECRET_ONE
- echo $SECRET_TWO
- name: Using SECRET_TWO
commands:
- checkout
- echo $SECRET_TWO
- ls -l .semaphore
secrets:
- name: mySecrets
- name: more-mihalis-secrets
Although it is allowed to have .semaphore/semaphore.yml files without
name properties, it is considered a very bad practice and should be
avoided.
However, the following sample .semaphore/semaphore.yml file proves
that it can be done:
version: v1.0
name: Basic YAML configuration file example.
agent:
machine:
type: e1-standard-2
os_image: ubuntu1804
blocks:
- task:
jobs:
- commands:
- echo $SEMAPHORE_PIPELINE_ID
- echo "Hello World!"
You cannot and you should not make any assumptions about the order the various
jobs items of a task are going to be executed. This means that the jobs of
a task item might not start in the order of definition.
However, the blocks items of a .semaphore/semaphore.yml file, which are
task items, are executed sequentially. This means that if you have two task
items on a .semaphore/semaphore.yml file, the second one will begin only
when the first one has finished.
Last, the jobs of a block will run in parallel provided that you have the required capacity (boxes) available.
Lines that begin with # are considered comments and are being ignored by the
YAML parser, which is not a Semaphore 2.0 feature but the way YAML files work.