Update README.md

I replaced "merge requests" by "commits". As far as I notice, merge requests per se don't trigger CI; commits and pushes (which are essentially adding commits) do. This is logical: an MR doesn't create anything new, so there is nothing to test.
This commit is contained in:
Alex Karnovsky 2017-03-08 11:46:06 +00:00
parent e78a366925
commit f6ba5ba874

View file

@ -6,7 +6,7 @@ projects.
GitLab offers a [continuous integration][ci] service. If you GitLab offers a [continuous integration][ci] service. If you
[add a `.gitlab-ci.yml` file][yaml] to the root directory of your repository, [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 and configure your GitLab project to use a [Runner], then each commit or
push, triggers your CI [pipeline]. push, triggers your CI [pipeline].
The `.gitlab-ci.yml` file tells the GitLab runner what to do. By default it runs The `.gitlab-ci.yml` file tells the GitLab runner what to do. By default it runs
@ -14,8 +14,8 @@ a pipeline with three [stages]: `build`, `test`, and `deploy`. You don't need to
use all three stages; stages with no jobs are simply ignored. use all three stages; stages with no jobs are simply ignored.
If everything runs OK (no non-zero return values), you'll get a nice green 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 checkmark associated with the commit. This makes it
easy to see whether a merge request caused any of the tests to fail before easy to see whether a commit caused any of the tests to fail before
you even look at the code. you even look at the code.
Most projects use GitLab's CI service to run the test suite so that Most projects use GitLab's CI service to run the test suite so that