diff options
author | Achilleas Pipinellis <axilleas@axilleas.me> | 2016-10-17 17:00:30 +0200 |
---|---|---|
committer | Achilleas Pipinellis <axilleas@axilleas.me> | 2016-10-27 19:20:16 +0200 |
commit | 4392098e12328e07c4d007585288e61e8926640b (patch) | |
tree | 973e223534e26f58bddddda0b2c0c8e3a2143766 /doc | |
parent | fdd52a6b237f22d06df38ba6fb879ae83c186a75 (diff) | |
download | gitlab-ce-4392098e12328e07c4d007585288e61e8926640b.tar.gz |
Fully document the pipelines settings page
Diffstat (limited to 'doc')
-rw-r--r-- | doc/ci/README.md | 1 | ||||
-rw-r--r-- | doc/ci/pipelines.md | 49 | ||||
-rw-r--r-- | doc/user/project/img/project_settings_list.png | bin | 10788 -> 11404 bytes | |||
-rw-r--r-- | doc/user/project/pipelines/img/pipelines_settings_badges.png | bin | 0 -> 56166 bytes | |||
-rw-r--r-- | doc/user/project/pipelines/settings.md | 101 |
5 files changed, 111 insertions, 40 deletions
diff --git a/doc/ci/README.md b/doc/ci/README.md index 341bc85a16a..6b90940c047 100644 --- a/doc/ci/README.md +++ b/doc/ci/README.md @@ -19,4 +19,5 @@ - [Build permissions](../user/permissions.md#build-permissions) - [API](../api/ci/README.md) - [CI services (linked docker containers)](services/README.md) +- [CI/CD pipelines settings](../user/project/pipelines/settings.md) - [**New CI build permissions model**](../user/project/new_ci_build_permissions_model.md) Read about what changed in GitLab 8.12 and how that affects your builds. There's a new way to access your Git submodules and LFS objects in builds. diff --git a/doc/ci/pipelines.md b/doc/ci/pipelines.md index a28f6f3ecdc..7d100a4fd93 100644 --- a/doc/ci/pipelines.md +++ b/doc/ci/pipelines.md @@ -5,9 +5,9 @@ Introduced in GitLab 8.8. ## Pipelines -A pipeline is a group of [builds] that get executed in [stages] \(batches). All -of the builds in a stage are executed in parallel (if there are enough -concurrent [runners]), and if they all succeed, the pipeline moves on to the +A pipeline is a group of [builds][] that get executed in [stages][](batches). +All of the builds in a stage are executed in parallel (if there are enough +concurrent [Runners]), and if they all succeed, the pipeline moves on to the next stage. If one of the builds fails, the next stage is not (usually) executed. @@ -25,8 +25,8 @@ See full [documentation](yaml/README.md#jobs). ## Seeing pipeline status -You can find the current and historical pipeline runs under **Pipelines** for your -project. +You can find the current and historical pipeline runs under **Pipelines** for +your project. ## Seeing build status @@ -36,42 +36,11 @@ cancel the build, retry it, or erase the build trace. ## Badges -Build status and test coverage report badges are available. - -Go to pipeline settings to see available badges and code you can use to embed -badges in the `README.md` or on the website. - -### Build status badge - -You can access a build status badge image using the following link: - -``` -http://example.gitlab.com/namespace/project/badges/branch/build.svg -``` - -### Test coverage report badge - -GitLab makes it possible to define the regular expression for coverage report, -that each build log will be matched against. This means that each build in the -pipeline can have the test coverage percentage value defined. - -You can access the test coverage badge using following link: - -``` -http://example.gitlab.com/namespace/project/badges/branch/coverage.svg -``` - -If you would like to get the coverage report from the specific job, you can add -a `job=coverage_job_name` parameter to the URL. For example, it is possible to -use following Markdown code to embed the test coverage report into `README.md`: - -```markdown -![coverage](http://gitlab.com/gitlab-org/gitlab-ce/badges/master/coverage.svg?job=coverage) -``` - -The latest successful pipeline will be used to read the test coverage value. +Build status and test coverage report badges are available. You can find their +respective link in the [Pipelines settings] page. [builds]: #builds [jobs]: yaml/README.md#jobs [stages]: yaml/README.md#stages -[runners]: runners/README.md +[runners]: runners/READM +[pipelines settings]: ../user/project/pipelines/settings.md diff --git a/doc/user/project/img/project_settings_list.png b/doc/user/project/img/project_settings_list.png Binary files differindex 57ca2ac5f9e..cd9f5c00eea 100644 --- a/doc/user/project/img/project_settings_list.png +++ b/doc/user/project/img/project_settings_list.png diff --git a/doc/user/project/pipelines/img/pipelines_settings_badges.png b/doc/user/project/pipelines/img/pipelines_settings_badges.png Binary files differnew file mode 100644 index 00000000000..d0c4640791d --- /dev/null +++ b/doc/user/project/pipelines/img/pipelines_settings_badges.png diff --git a/doc/user/project/pipelines/settings.md b/doc/user/project/pipelines/settings.md new file mode 100644 index 00000000000..9641792d0bb --- /dev/null +++ b/doc/user/project/pipelines/settings.md @@ -0,0 +1,101 @@ +# CI/CD pipelines settings + +To reach the pipelines settings: + +1. Navigate to your project and click the cog icon in the upper right corner. + + ![Project settings menu](../img/project_settings_list.png) + +1. Select **CI/CD Pipelines** from the menu. + +The following settings can be configured per project. + +## Git strategy + +With Git strategy, you can choose the default way your repository is fetched +from GitLab in a job. + +There are two options: + +- Using `git clone` which is slower since it clones the repository from scratch + for every job, ensuring that the project workspace is always pristine. +- Using `git fetch` which is faster as it re-uses the project workspace (falling + back to clone if it doesn't exist). + +The default Git strategy can be overridden by the [GIT_STRATEGY variable][var] +in `.gitlab-ci.yml`. + +## Timeout + +Timeout defines the maximum amount of time in minutes that a job is able run. +The default value is 60 minutes. Decrease the time limit if you want to impose +a hard limit on your jobs' running time or increase it otherwise. In any case, +if the job surpasses the threshold, it is marked as failed. + +## Test coverage parsing + +If you use test coverage in your code, GitLab can capture its output in the +build trace using a regular expression. Leave blank if you want to disable it +or enter a ruby regular expression. You can use http://rubular.com to test your +regex. + +A few examples can be found in the settings page. + +## Visibility of pipelines + +For public and internal projects, the **Pipelines** page can be accessed by +anyone and those logged in respectively. If you wish to hide it so that only +the members of the project or group have access to it, uncheck the **Public +pipelines** checkbox and save the changes. + +## Badges + +In the pipelines settings page you can find build status and test coverage +badges for your project. The latest successful pipeline will be used to read +the build status and test coverage values. + +Visit the **Pipelines** settings page in your project to see the exact link to +your badges, as well as ways to embed the badge image in your HTML or Markdown +pages. + +![Pipelines badges](img/pipelines_settings_badges.png) + +### Build status badge + +Depending on the status of your build, a badge can have the following values: + +- running +- success +- failed +- skipped +- unknown + +You can access a build status badge image using the following link: + +``` +https://example.gitlab.com/<namespace>/<project>/badges/<branch>/build.svg +``` + +### Test coverage report badge + +GitLab makes it possible to define the regular expression for [coverage report], +that each build log will be matched against. This means that each build in the +pipeline can have the test coverage percentage value defined. + +The test coverage badge can be accessed using following link: + +``` +https://example.gitlab.com/<namespace>/<project>/badges/<branch>/coverage.svg +``` + +If you would like to get the coverage report from a specific job, you can add +the `job=coverage_job_name` parameter to the URL. For example, the following +Markdown code will embed the test coverage report badge of the `coverage` job +into your `README.md`: + +```markdown +![coverage](https://gitlab.com/gitlab-org/gitlab-ce/badges/master/coverage.svg?job=coverage) +``` + +[var]: ../../../ci/yaml/README.md#git-strategy +[coverage report]: #test-coverage-parsing |