From 68af55c3f93be79841957ff12b736e104fdc40de Mon Sep 17 00:00:00 2001 From: Daniel Klischies Date: Fri, 21 Oct 2016 18:38:11 +0000 Subject: Add a note regarding syncing the git submodule conf to CI doc. --- doc/user/project/new_ci_build_permissions_model.md | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'doc/user') diff --git a/doc/user/project/new_ci_build_permissions_model.md b/doc/user/project/new_ci_build_permissions_model.md index 8827b501901..608475116a1 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: -- cgit v1.2.1 From 94ceadb4a32a4a5128d43983206518d3159354e0 Mon Sep 17 00:00:00 2001 From: Winnie Date: Fri, 21 Oct 2016 20:18:03 +0000 Subject: Document link syntax introduced by !5586 --- doc/user/markdown.md | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'doc/user') 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][] -- cgit v1.2.1 From 692eb3f84e912bd586f923bd87737bd15ae3b750 Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Tue, 25 Oct 2016 10:50:29 +0200 Subject: Capitalize Git [ci skip] --- doc/user/project/new_ci_build_permissions_model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/user') diff --git a/doc/user/project/new_ci_build_permissions_model.md b/doc/user/project/new_ci_build_permissions_model.md index 608475116a1..60b7bec2ba7 100644 --- a/doc/user/project/new_ci_build_permissions_model.md +++ b/doc/user/project/new_ci_build_permissions_model.md @@ -254,7 +254,7 @@ 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, +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 -- cgit v1.2.1 From 4392098e12328e07c4d007585288e61e8926640b Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Mon, 17 Oct 2016 17:00:30 +0200 Subject: Fully document the pipelines settings page --- doc/user/project/img/project_settings_list.png | Bin 10788 -> 11404 bytes .../pipelines/img/pipelines_settings_badges.png | Bin 0 -> 56166 bytes doc/user/project/pipelines/settings.md | 101 +++++++++++++++++++++ 3 files changed, 101 insertions(+) create mode 100644 doc/user/project/pipelines/img/pipelines_settings_badges.png create mode 100644 doc/user/project/pipelines/settings.md (limited to 'doc/user') diff --git a/doc/user/project/img/project_settings_list.png b/doc/user/project/img/project_settings_list.png index 57ca2ac5f9e..cd9f5c00eea 100644 Binary files a/doc/user/project/img/project_settings_list.png and b/doc/user/project/img/project_settings_list.png differ diff --git a/doc/user/project/pipelines/img/pipelines_settings_badges.png b/doc/user/project/pipelines/img/pipelines_settings_badges.png new file mode 100644 index 00000000000..d0c4640791d Binary files /dev/null and b/doc/user/project/pipelines/img/pipelines_settings_badges.png differ 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///badges//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///badges//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 -- cgit v1.2.1 From 6309fbf120c9f1c152645fb5cc6053b3a04edc6c Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Mon, 17 Oct 2016 20:41:24 +0200 Subject: Add more images for the test coverage docs --- .../img/pipelines_settings_test_coverage.png | Bin 0 -> 4212 bytes .../img/pipelines_test_coverage_build.png | Bin 0 -> 9953 bytes .../img/pipelines_test_coverage_mr_widget.png | Bin 0 -> 14502 bytes doc/user/project/pipelines/settings.md | 24 +++++++++++++++------ 4 files changed, 18 insertions(+), 6 deletions(-) create mode 100644 doc/user/project/pipelines/img/pipelines_settings_test_coverage.png create mode 100644 doc/user/project/pipelines/img/pipelines_test_coverage_build.png create mode 100644 doc/user/project/pipelines/img/pipelines_test_coverage_mr_widget.png (limited to 'doc/user') diff --git a/doc/user/project/pipelines/img/pipelines_settings_test_coverage.png b/doc/user/project/pipelines/img/pipelines_settings_test_coverage.png new file mode 100644 index 00000000000..d2a5568521f Binary files /dev/null and b/doc/user/project/pipelines/img/pipelines_settings_test_coverage.png differ diff --git a/doc/user/project/pipelines/img/pipelines_test_coverage_build.png b/doc/user/project/pipelines/img/pipelines_test_coverage_build.png new file mode 100644 index 00000000000..3823100daf2 Binary files /dev/null and b/doc/user/project/pipelines/img/pipelines_test_coverage_build.png differ 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 new file mode 100644 index 00000000000..c4f78803e69 Binary files /dev/null and b/doc/user/project/pipelines/img/pipelines_test_coverage_mr_widget.png differ diff --git a/doc/user/project/pipelines/settings.md b/doc/user/project/pipelines/settings.md index 9641792d0bb..6cbcf3c400f 100644 --- a/doc/user/project/pipelines/settings.md +++ b/doc/user/project/pipelines/settings.md @@ -35,15 +35,27 @@ 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. +build log using a regular expression. In the pipelines settings, search for the +"Test coverage parsing" section. -A few examples can be found in the settings page. +![Pipelines settings test coverage](img/pipelines_settings_test_coverage.png) + +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. + +![MR widget coverage](img/pipelines_test_coverage_mr_widget.png) + +![Build status coverage](img/pipelines_test_coverage_build.png) + +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 +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. @@ -54,7 +66,7 @@ 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 +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. -- cgit v1.2.1