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

Update README.md

Browse source 
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
1 changed files with 3 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
doc/ci/quick_start/README.md
View file

@ -6,7 +6,7 @@ projects.
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
and configure your GitLab project to use a [Runner], then each commit or
push, triggers your CI [pipeline].
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.
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 caused any of the tests to fail before
checkmark associated with the commit. This makes it
easy to see whether a commit caused any of the tests to fail before
you even look at the code.
Most projects use GitLab's CI service to run the test suite so that