diff options
author | Alex Karnovsky <alexk@almtoolbox.com> | 2017-03-08 11:46:06 +0000 |
---|---|---|
committer | Alex Karnovsky <alexk@almtoolbox.com> | 2017-03-08 11:46:06 +0000 |
commit | f6ba5ba87437c9b30f787797f00ce48a6aec8b06 (patch) | |
tree | cec592fe48d1b6ce2e870322d3ad7d997875d486 /doc/ci | |
parent | e78a366925553a1268f8dc6e0d57342053a3240a (diff) | |
download | gitlab-ce-f6ba5ba87437c9b30f787797f00ce48a6aec8b06.tar.gz |
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.
Diffstat (limited to 'doc/ci')
-rw-r--r-- | doc/ci/quick_start/README.md | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/doc/ci/quick_start/README.md b/doc/ci/quick_start/README.md index 2a5401ac13a..76e86f3e3c3 100644 --- a/doc/ci/quick_start/README.md +++ b/doc/ci/quick_start/README.md @@ -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 |