Commit b8a1f1c4 authored by Achilleas Pipinellis's avatar Achilleas Pipinellis

Merge branch 'ci_quickstart' into 'master'

Add a TL;DR version in quickstart guide



See merge request !3026
parents 9bbf873e d5f634b3
# Quick Start # Quick Start
Starting from version 8.0, GitLab Continuous Integration (CI) is fully >**Note:** Starting from version 8.0, GitLab [Continuous Integration][ci] (CI)
integrated into GitLab itself and is enabled by default on all projects. 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 root directory of your repository
1. Add `.gitlab-ci.yml` to the git repository and push to GitLab
1. Configure a Runner 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 automagically started by the Runner and will appear under the project's
`/builds` page. `/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 ## Creating a `.gitlab-ci.yml` file
...@@ -218,3 +240,8 @@ Visit our various languages examples at <https://gitlab.com/groups/gitlab-exampl ...@@ -218,3 +240,8 @@ Visit our various languages examples at <https://gitlab.com/groups/gitlab-exampl
[runner-install]: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/tree/master#installation [runner-install]: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/tree/master#installation
[blog-ci]: https://about.gitlab.com/2015/05/06/why-were-replacing-gitlab-ci-jobs-with-gitlab-ci-dot-yml/ [blog-ci]: https://about.gitlab.com/2015/05/06/why-were-replacing-gitlab-ci-jobs-with-gitlab-ci-dot-yml/
[examples]: ../examples/README.md [examples]: ../examples/README.md
[ci]: https://about.gitlab.com/gitlab-ci/
[yaml]: ../yaml/README.md
[runner]: ../runners/README.md
[enabled]: ../enable_or_disable_ci.md
[stages]: ../yaml/README.md#stages
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment