Commit f6ba5ba8 authored by Alex Karnovsky's avatar Alex Karnovsky

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.
parent e78a3669
......@@ -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
......
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