diff options
Diffstat (limited to 'doc/user')
| -rw-r--r-- | doc/user/markdown.md | 8 | ||||
| -rw-r--r-- | doc/user/project/img/project_settings_list.png | bin | 10788 -> 11404 bytes | |||
| -rw-r--r-- | doc/user/project/new_ci_build_permissions_model.md | 6 | ||||
| -rw-r--r-- | doc/user/project/pipelines/img/pipelines_settings_badges.png | bin | 0 -> 56166 bytes | |||
| -rw-r--r-- | doc/user/project/pipelines/img/pipelines_settings_test_coverage.png | bin | 0 -> 4212 bytes | |||
| -rw-r--r-- | doc/user/project/pipelines/img/pipelines_test_coverage_build.png | bin | 0 -> 9953 bytes | |||
| -rw-r--r-- | doc/user/project/pipelines/img/pipelines_test_coverage_mr_widget.png | bin | 0 -> 14502 bytes | |||
| -rw-r--r-- | doc/user/project/pipelines/settings.md | 113 |
8 files changed, 127 insertions, 0 deletions
diff --git a/doc/user/markdown.md b/doc/user/markdown.md index 56e5b802a52..7a7a0b864bd 100644 --- a/doc/user/markdown.md +++ b/doc/user/markdown.md @@ -501,6 +501,10 @@ There are two ways to create links, inline-style and reference-style. [I'm a reference-style link][Arbitrary case-insensitive reference text] [I'm a relative reference to a repository file](LICENSE) + + [I am an absolute reference within the repository](/doc/user/markdown.md) + + [I link to the Milestones page](/../milestones) [You can use numbers for reference-style link definitions][1] @@ -518,6 +522,10 @@ There are two ways to create links, inline-style and reference-style. [I'm a relative reference to a repository file](LICENSE)[^1] +[I am an absolute reference within the repository](/doc/user/markdown.md) + +[I link to the Milestones page](/../milestones) + [You can use numbers for reference-style link definitions][1] Or leave it empty and use the [link text itself][] 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/new_ci_build_permissions_model.md b/doc/user/project/new_ci_build_permissions_model.md index 8827b501901..60b7bec2ba7 100644 --- a/doc/user/project/new_ci_build_permissions_model.md +++ b/doc/user/project/new_ci_build_permissions_model.md @@ -254,6 +254,12 @@ test: This will make GitLab CI initialize (fetch) and update (checkout) all your submodules recursively. +If Git does not use the newly added relative URLs but still uses your old URLs, +you might need to add `git submodule sync --recursive` to your `.gitlab-ci.yml`, +prior to running `git submodule update --init --recursive`. This transfers the +changes from your `.gitmodules` file into the `.git` folder, which is kept by +runners between runs. + In case your environment or your Docker image doesn't have Git installed, you have to either ask your Administrator or install the missing dependency yourself: 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/img/pipelines_settings_test_coverage.png b/doc/user/project/pipelines/img/pipelines_settings_test_coverage.png Binary files differnew file mode 100644 index 00000000000..d2a5568521f --- /dev/null +++ b/doc/user/project/pipelines/img/pipelines_settings_test_coverage.png diff --git a/doc/user/project/pipelines/img/pipelines_test_coverage_build.png b/doc/user/project/pipelines/img/pipelines_test_coverage_build.png Binary files differnew file mode 100644 index 00000000000..3823100daf2 --- /dev/null +++ b/doc/user/project/pipelines/img/pipelines_test_coverage_build.png diff --git a/doc/user/project/pipelines/img/pipelines_test_coverage_mr_widget.png b/doc/user/project/pipelines/img/pipelines_test_coverage_mr_widget.png Binary files differnew file mode 100644 index 00000000000..c4f78803e69 --- /dev/null +++ b/doc/user/project/pipelines/img/pipelines_test_coverage_mr_widget.png diff --git a/doc/user/project/pipelines/settings.md b/doc/user/project/pipelines/settings.md new file mode 100644 index 00000000000..6cbcf3c400f --- /dev/null +++ b/doc/user/project/pipelines/settings.md @@ -0,0 +1,113 @@ +# CI/CD pipelines settings + +To reach the pipelines settings: + +1. Navigate to your project and click the cog icon in the upper right corner. + +  + +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 log using a regular expression. In the pipelines settings, search for the +"Test coverage parsing" section. + + + +Leave blank if you want to disable it or enter a ruby regular expression. You +can use http://rubular.com to test your regex. + +If the pipeline succeeds, the coverage is shown in the merge request widget and +in the builds table. + + + + + +A few examples of known coverage tools for a variety of languages can be found +in the pipelines 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. + + + +### 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 + +``` + +[var]: ../../../ci/yaml/README.md#git-strategy +[coverage report]: #test-coverage-parsing |
