Configuration of your builds with. It is placed in the root of your repository and contains definitions of how your project should be built. The jobs are defined as top-level elements with a name and always have to contain at least the script clause: image: ruby:2. The configuration of this feature is covered in. This can gitlab ci yaml an array or a multi-line string. This has to be an array or a multi-line string. The specification of stages allows for having flexible multi stage pipelines. For implementation details, please check GitLab Runner. The key directive allows you to define the affinity of caching between jobs, allowing to have a single cache for all jobs, cache per-job, cache per-branch or any other way you deem proper. This allows you to fine tune caching, allowing you to cache data between different jobs or even different branches. The cache:key variable can use any of the. Failed build doesn't contribute to commit status when no Define when to run build. Manual actions Note: Introduced in GitSwarm 2016. Manual actions are a special type of job that are not executed automatically; they need to be explicitly started by a user. Manual actions can be started from pipeline, build, environment, and deployment views. You can execute the same manual action multiple times. An example usage of manual actions is deployment to production. This allows easy tracking of all deployments to your environments straight from GitSwarm. If environment is specified and no environment under that name exists, a new one will be created automatically. Common names are qa, staging, and production, but you can use whatever name works with your workflow. To pass gitlab ci yaml between different builds, see. Send all files in binaries and. The name directive allows you to define the name of the created artifacts gitlab ci yaml. That way, you can have a unique name for every archive which could be useful when you'd like to download the archive from GitSwarm. The artifacts:name variable can make use of any of the. The default name is artifacts, which becomes artifacts. Example configurations To upload artifacts only when build fails. By default, artifacts are stored on GitSwarm forever. You can use the Keep button on the build page to override expiration and keep artifacts forever. After expiry, artifacts are actually deleted hourly by default via a cron jobbut they are not accessible after expiry. This feature should be used in conjunction with and allows you to define the artifacts to pass between different builds. Note that artifacts from all previous are passed by default. To use this feature, define dependencies in context of the job and pass a list of all previous builds from which the artifacts should be downloaded. You can only gitlab ci yaml builds from stages that are executed before the current one. An error will be shown if you define builds from the current stage or next ones. Defining an empty array will skip downloading any artifacts for that job. In the following example, we define two jobs with artifacts, build:osx and build:linux. When the test:osx is executed, the artifacts from build:osx will be downloaded and extracted in the context of the build. The same happens for test:linux and artifacts from build:linux. May change in future releases or be removed completely. If it's not specified, then the default from project settings will be used. May change in future releases or be removed completely. This allows shallow cloning of the repository which can significantly speed up cloning for repositories with a large number of commits or old, large binaries. The value is passed to git fetch and git clone. Note: If you use a depth of 1 and have a queue of builds or retry builds, jobs may fail. If there are multiple builds in the queue, or you are retrying an old build, the commit to be tested needs to be within the git history that is cloned. You will see unresolved reference in build logs. Jobs that start with a dot. You can use this feature to ignore jobs, or use the and transform the hidden jobs into templates.
