@@ -20,6 +20,22 @@ Of course a command can execute code directly (`./configure;make;make install`)
Jobs are used to create builds, which are then picked up by [runners](../runners/README.md) and executed within the environment of the runner.
What is important, is that each job is run independently from each other.
## Why `.gitlab-ci.yml`
By placing a single configuration file in the root of your repository,
it is version controlled and you get all the advantages of git.
In addition, builds for older versions of the repository will work just fine,
as GitLab look at the `.gitlab-ci.yml` of the pushed commit.
This means that forks also build without any problem.
You can even set up different builds for different branches. This allows you
to only deploy the `production` branch, for instance.
By having a single source of truth, everyone can view and contribute to the
stability of your CI builds, eventually improving the quality of your development
cycle.
## .gitlab-ci.yml
The YAML syntax allows for using more complex job specifications than in the above example:
Loading
Loading
@@ -201,4 +217,4 @@ Each instance of GitLab CI has an embedded debug tool called Lint.
You can find the link to the Lint in the project's settings page or use short url `/lint`.
## Skipping builds
There is one more way to skip all builds, if your commit message contains tag [ci skip]. In this case, commit will be created but builds will be skipped
\ No newline at end of file
There is one more way to skip all builds, if your commit message contains tag [ci skip]. In this case, commit will be created but builds will be skipped
