Welcome to mirror list, hosted at ThFree Co, Russian Federation.

gitlab.com/gitlab-org/gitlab-foss.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat (limited to 'doc/ci/pipelines/settings.md')
-rw-r--r--doc/ci/pipelines/settings.md88
1 files changed, 60 insertions, 28 deletions
diff --git a/doc/ci/pipelines/settings.md b/doc/ci/pipelines/settings.md
index e22746dbfa0..7960d0afa85 100644
--- a/doc/ci/pipelines/settings.md
+++ b/doc/ci/pipelines/settings.md
@@ -190,18 +190,13 @@ You can define how long a job can run before it times out.
1. On the left sidebar, select **Settings > CI/CD**.
1. Expand **General pipelines**.
1. In the **Timeout** field, enter the number of minutes, or a human-readable value like `2 hours`.
+ Must be 10 minutes or more, and less than one month. Default is 60 minutes.
Jobs that exceed the timeout are marked as failed.
You can override this value [for individual runners](../runners/configure_runners.md#set-maximum-job-timeout-for-a-runner).
-## Add test coverage results to a merge request (DEPRECATED)
-
-> [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/17633) in GitLab 14.9. Replaced by [`coverage` keyword](../yaml/index.md#coverage).
-
-WARNING:
-This feature is in its end-of-life process. It is [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/17633)
-for use in GitLab 14.9, and is planned for [removal](https://gitlab.com/gitlab-org/gitlab/-/issues/17633) in GitLab 15.0.
+## Merge request test coverage results
If you use test coverage in your code, you can use a regular expression to
find coverage results in the job log. You can then include these results
@@ -215,27 +210,38 @@ averaged.
![Build status coverage](img/pipelines_test_coverage_build.png)
-To define a coverage-parsing regular expression:
+### Add test coverage results using `coverage` keyword
+
+To add test coverage results to a merge request using the project's `.gitlab-ci.yml` file, provide a regular expression
+using the [`coverage`](../yaml/index.md#coverage) keyword.
+
+Setting the regular expression this way takes precedence over project settings.
+
+### Add test coverage results using project settings (DEPRECATED)
+
+> [Deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/17633) in GitLab 14.9. Replaced by [`coverage` keyword](../yaml/index.md#coverage).
+
+WARNING:
+This feature is in its end-of-life process. It is [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/17633)
+for use in GitLab 14.9, and is planned for [removal](https://gitlab.com/gitlab-org/gitlab/-/issues/17633) in GitLab 15.0.
-- Using the project's `.gitlab-ci.yml`, provide a regular expression using the [`coverage`](../yaml/index.md#coverage)
- keyword. Setting the regular expression this way takes precedence over the project's CI/CD settings.
+You can add test coverage results to merge requests using the Project's CI/CD settings:
-- Using the Project's CI/CD settings:
- - Set using the GitLab UI:
+- Set using the GitLab UI:
- 1. On the top bar, select **Menu > Projects** and find your project.
- 1. On the left sidebar, select **Settings > CI/CD**.
- 1. Expand **General pipelines**.
- 1. In the **Test coverage parsing** field, enter a regular expression. Leave blank to disable this feature.
+ 1. On the top bar, select **Menu > Projects** and find your project.
+ 1. On the left sidebar, select **Settings > CI/CD**.
+ 1. Expand **General pipelines**.
+ 1. In the **Test coverage parsing** field, enter a regular expression. Leave blank to disable this feature.
- - Set when [editing a project](../../api/projects.md#edit-project) or [creating a project](../../api/projects.md#create-project)
- using the GitLab API with the `build_coverage_regex` attribute:
+- Set when [editing a project](../../api/projects.md#edit-project) or [creating a project](../../api/projects.md#create-project)
+ using the GitLab API with the `build_coverage_regex` attribute:
- ```shell
- curl --request PUT --header "PRIVATE-TOKEN: <your-token>" \
- --url 'https://gitlab.com/api/v4/projects/<your-project-ID>' \
- --data "build_coverage_regex=<your-regular-expression>"
- ```
+ ```shell
+ curl --request PUT --header "PRIVATE-TOKEN: <your-token>" \
+ --url 'https://gitlab.com/api/v4/projects/<your-project-ID>' \
+ --data "build_coverage_regex=<your-regular-expression>"
+ ```
You can use <https://rubular.com> to test your regular expression. The regular expression returns the **last**
match found in the output.
@@ -324,7 +330,15 @@ lein cloverage | perl -pe 's/\e\[?.*?[\@-~]//g'
Pipeline badges indicate the pipeline status and a test coverage value
for your project. These badges are determined by the latest successful pipeline.
-### View the code for the pipeline status and coverage reports badges
+## Latest release badge
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/33368) in GitLab 14.8.
+
+A latest release badge indicates the latest release tag name for your project.
+By default, the badge fetches the release sorted using the [`released_at`](../../api/releases/index.md#create-a-release) time.
+Support for [`semver`](https://semver.org/) sorting is tracked [in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/352945).
+
+### View the code for the pipeline status, coverage reports, and latest release badges
You can view the exact link for your badges. Then you can embed the badge in your HTML
or Markdown pages.
@@ -332,7 +346,7 @@ or Markdown pages.
1. On the top bar, select **Menu > Projects** and find your project.
1. On the left sidebar, select **Settings > CI/CD**.
1. Expand **General pipelines**.
-1. In the **Pipeline status** or **Coverage report** sections, view the URLs for the images.
+1. In the **Pipeline status**, **Coverage report**, or **Latest release** sections, view the URLs for the images.
![Pipelines badges](img/pipelines_settings_badges.png)
@@ -364,9 +378,8 @@ https://gitlab.example.com/<namespace>/<project>/badges/<branch>/pipeline.svg?ig
### Test coverage report badge
-You can define the regular expression for the [coverage report](#add-test-coverage-results-to-a-merge-request-deprecated)
-that each job log is matched against. This means that each job in the
-pipeline can have the test coverage percentage value defined.
+You can define the regular expression for the [coverage report](#merge-request-test-coverage-results) that each job log
+is matched against. This means that each job in the pipeline can have the test coverage percentage value defined.
To access the test coverage badge, use the following link:
@@ -406,6 +419,25 @@ If an invalid boundary is set, GitLab automatically adjusts it to be valid. For
if `min_good` is set `80`, and `min_acceptable` is set to `85` (too high), GitLab automatically
sets `min_acceptable` to `79` (`min_good` - `1`).
+### Latest release badge
+
+When a release exists in your project, it shows the latest release tag name. If there is no release,
+it shows `none`.
+
+You can access a latest release badge image by using the following link:
+
+```plaintext
+https://gitlab.example.com/<namespace>/<project>/-/badges/release.svg
+```
+
+#### Sorting preferences
+
+By default, the latest release badge fetches the release using `release_at` time. The use of the query parameter `?order_by=release_at` is optional, and support for `?order_by=semver` is tracked [in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/352945):
+
+```plaintext
+https://gitlab.example.com/<namespace>/<project>/-/badges/release.svg?order_by=release_at
+```
+
### Badge styles
Pipeline badges can be rendered in different styles by adding the `style=style_name` parameter to the URL. Two styles are available: