kotovalexarian-likes-gitlab
/
gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

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]
This commit is contained in:
Achilleas Pipinellis 2016-03-01 10:26:53 +02:00
parent 581da235bf
commit d5f634b32f
1 changed files with 40 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
doc/ci/quick_start/README.md
View File

@ -1,7 +1,39 @@
# 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.
The TL;DR version of how GitLab CI works is the following.
---
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.
So in brief, the steps needed to have a working CI can be summed up to:
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
automagically started by the Runner and will appear under the project's
`/builds` page.
---
This guide assumes that you:
@ -9,17 +41,7 @@ This guide assumes that you:
[GitLab.com](https://gitlab.com/users/sign_in)
- have a project in GitLab that you would like to use CI for
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. Configure a Runner
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.
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 <https://gitlab.com/groups/gitlab-exampl
[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/
[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