From d5f634b32fdd2f47239d3df5b9995d8cd2606df3 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Tue, 1 Mar 2016 10:26:53 +0200 Subject: Add a TL;DR version in quick start guide Borrowed from a user's comment: https://gitlab.com/esr/reposurgeon/merge_requests/27#note_3158109 [ci skip] --- doc/ci/quick_start/README.md | 49 ++++++++++++++++++++++++++++++++++---------- 1 file changed, 38 insertions(+), 11 deletions(-) diff --git a/doc/ci/quick_start/README.md b/doc/ci/quick_start/README.md index 5af7be5581e..624d9899c79 100644 --- a/doc/ci/quick_start/README.md +++ b/doc/ci/quick_start/README.md @@ -1,25 +1,47 @@ # Quick Start -Starting from version 8.0, GitLab Continuous Integration (CI) is fully -integrated into GitLab itself and is enabled by default on all projects. +>**Note:** Starting from version 8.0, GitLab [Continuous Integration][ci] (CI) +is fully integrated into GitLab itself and is [enabled] by default on all +projects. -This guide assumes that you: +The TL;DR version of how GitLab CI works is the following. -- have a working GitLab instance of version 8.0 or higher or are using - [GitLab.com](https://gitlab.com/users/sign_in) -- have a project in GitLab that you would like to use CI for +--- + +GitLab offers a [continuous integration][ci] service. If you +[add a `.gitlab-ci.yml` file][yaml] to the root directory of your repository, +and configure your GitLab project to use a [Runner], then each merge request or +push triggers a build. + +The `.gitlab-ci.yml` file tells the GitLab runner what do to. By default it +runs three [stages]: `build`, `test`, and `deploy`. + +If everything runs OK (no non-zero return values), you'll get a nice green +checkmark associated with the pushed commit or merge request. This makes it +easy to see whether a merge request will cause any of the tests to fail before +you even look at the code. + +Most projects only use GitLab's CI service to run the test suite so that +developers get immediate feedback if they broke something. -In brief, the steps needed to have a working CI can be summed up to: +So in brief, the steps needed to have a working CI can be summed up to: -1. Create a new project -1. Add `.gitlab-ci.yml` to the git repository and push to GitLab +1. Add `.gitlab-ci.yml` to the root directory of your repository 1. Configure a Runner -From there on, on every push to your git repository the build will be +From there on, on every push to your Git repository, the build will be automagically started by the Runner and will appear under the project's `/builds` page. -Now, let's break it down to pieces and work on solving the GitLab CI puzzle. +--- + +This guide assumes that you: + +- have a working GitLab instance of version 8.0 or higher or are using + [GitLab.com](https://gitlab.com/users/sign_in) +- have a project in GitLab that you would like to use CI for + +Let's break it down to pieces and work on solving the GitLab CI puzzle. ## Creating a `.gitlab-ci.yml` file @@ -218,3 +240,8 @@ Visit our various languages examples at