diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-03-27 03:07:56 +0000 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-03-27 03:07:56 +0000 |
commit | 4560c92ab1954cf0416bafc45d1fa671fcacb3c3 (patch) | |
tree | 4b70c6b61345b2df075918cab6314d41b46cf80e /doc/topics/gitlab_flow.md | |
parent | 6348b76e4b4dd4e398915c3150c1d02aafa3f13b (diff) | |
download | gitlab-ce-4560c92ab1954cf0416bafc45d1fa671fcacb3c3.tar.gz |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/topics/gitlab_flow.md')
-rw-r--r-- | doc/topics/gitlab_flow.md | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/doc/topics/gitlab_flow.md b/doc/topics/gitlab_flow.md index 0fab4de8454..fb47899c585 100644 --- a/doc/topics/gitlab_flow.md +++ b/doc/topics/gitlab_flow.md @@ -309,7 +309,7 @@ In old workflows, the continuous integration (CI) server commonly ran tests on t Developers had to ensure their code did not break the `master` branch. When using GitLab flow, developers create their branches from this `master` branch, so it is essential that it never breaks. Therefore, each merge request must be tested before it is accepted. -CI software like Travis CI and GitLab CI show the build results right in the merge request itself to make this easy. +CI software like Travis CI and GitLab CI/CD show the build results right in the merge request itself to make this easy. There is one drawback to testing merge requests: the CI server only tests the feature branch itself, not the merged result. Ideally, the server could also test the `master` branch after each change. |