diff options
Diffstat (limited to 'doc/ci/pipelines')
| -rw-r--r-- | doc/ci/pipelines/cicd_minutes.md | 22 | ||||
| -rw-r--r-- | doc/ci/pipelines/img/pipeline_schedule_play.png | bin | 11400 -> 0 bytes | |||
| -rw-r--r-- | doc/ci/pipelines/img/pipeline_schedule_variables.png | bin | 6300 -> 0 bytes | |||
| -rw-r--r-- | doc/ci/pipelines/img/pipeline_schedules_list.png | bin | 12948 -> 0 bytes | |||
| -rw-r--r-- | doc/ci/pipelines/img/pipeline_schedules_new_form.png | bin | 20090 -> 0 bytes | |||
| -rw-r--r-- | doc/ci/pipelines/img/pipeline_schedules_ownership.png | bin | 5004 -> 0 bytes | |||
| -rw-r--r-- | doc/ci/pipelines/index.md | 22 | ||||
| -rw-r--r-- | doc/ci/pipelines/merge_request_pipelines.md | 4 | ||||
| -rw-r--r-- | doc/ci/pipelines/merge_trains.md | 4 | ||||
| -rw-r--r-- | doc/ci/pipelines/merged_results_pipelines.md | 2 | ||||
| -rw-r--r-- | doc/ci/pipelines/pipelines_for_merged_results.md | 4 | ||||
| -rw-r--r-- | doc/ci/pipelines/schedules.md | 159 | ||||
| -rw-r--r-- | doc/ci/pipelines/settings.md | 88 |
13 files changed, 150 insertions, 155 deletions
diff --git a/doc/ci/pipelines/cicd_minutes.md b/doc/ci/pipelines/cicd_minutes.md index 8b10a74bd78..f9d9a4f738b 100644 --- a/doc/ci/pipelines/cicd_minutes.md +++ b/doc/ci/pipelines/cicd_minutes.md @@ -223,3 +223,25 @@ On GitLab SaaS an email notification is sent to the namespace owners when: - The available CI/CD minutes are below 30% of the quota. - The available CI/CD minutes are below 5% of the quota. - All CI/CD minutes have been used. + +## Reduce consumption of CI/CD minutes + +If your project consumes too many CI/CD minutes, there are some strategies you can +use to reduce your CI/CD minutes usage: + +- If you are using project mirrors, ensure that [pipelines for mirror updates](../../user/project/repository/mirror/pull.md#trigger-pipelines-for-mirror-updates) + is disabled. +- Reduce the frequency of [scheduled pipelines](schedules.md). +- [Skip pipelines](index.md#skip-a-pipeline) when not needed. +- Use [interruptible](../yaml/index.md#interruptible) jobs which can be auto-canceled + if a new pipeline starts. +- If a job doesn't have to run in every pipeline, use [`rules`](../jobs/job_control.md) + to make it only run when it's needed. +- [Use private runners](../runners/runners_scope.md#group-runners) for some jobs. +- If you are working from a fork and you submit a merge request to the parent project, + you can ask a maintainer to run a pipeline [in the parent project](merge_request_pipelines.md#run-pipelines-in-the-parent-project). + +If you manage an open source project, these improvements can also reduce CI/CD minutes +consumption for contributor fork projects, enabling more contributions. + +See our [pipeline efficiency guide](pipeline_efficiency.md) for more details. diff --git a/doc/ci/pipelines/img/pipeline_schedule_play.png b/doc/ci/pipelines/img/pipeline_schedule_play.png Binary files differdeleted file mode 100644 index ec6eb0d156b..00000000000 --- a/doc/ci/pipelines/img/pipeline_schedule_play.png +++ /dev/null diff --git a/doc/ci/pipelines/img/pipeline_schedule_variables.png b/doc/ci/pipelines/img/pipeline_schedule_variables.png Binary files differdeleted file mode 100644 index ce3c3dc6af1..00000000000 --- a/doc/ci/pipelines/img/pipeline_schedule_variables.png +++ /dev/null diff --git a/doc/ci/pipelines/img/pipeline_schedules_list.png b/doc/ci/pipelines/img/pipeline_schedules_list.png Binary files differdeleted file mode 100644 index 541fe4f9b1d..00000000000 --- a/doc/ci/pipelines/img/pipeline_schedules_list.png +++ /dev/null diff --git a/doc/ci/pipelines/img/pipeline_schedules_new_form.png b/doc/ci/pipelines/img/pipeline_schedules_new_form.png Binary files differdeleted file mode 100644 index 993fbf8ca00..00000000000 --- a/doc/ci/pipelines/img/pipeline_schedules_new_form.png +++ /dev/null diff --git a/doc/ci/pipelines/img/pipeline_schedules_ownership.png b/doc/ci/pipelines/img/pipeline_schedules_ownership.png Binary files differdeleted file mode 100644 index 8fc5c5fbc82..00000000000 --- a/doc/ci/pipelines/img/pipeline_schedules_ownership.png +++ /dev/null diff --git a/doc/ci/pipelines/index.md b/doc/ci/pipelines/index.md index 5a5fd2b5540..4d1af735b13 100644 --- a/doc/ci/pipelines/index.md +++ b/doc/ci/pipelines/index.md @@ -140,7 +140,7 @@ to its **Pipelines** tab.  -Click a pipeline to open the **Pipeline Details** page and show +Select a pipeline to open the **Pipeline Details** page and show the jobs that were run for that pipeline. From here you can cancel a running pipeline, retry jobs on a failed pipeline, or [delete a pipeline](#delete-a-pipeline). @@ -246,7 +246,7 @@ For each `var` or `file_var`, a key and value are required. [Manual jobs](../jobs/job_control.md#create-a-job-that-must-be-run-manually), allow you to require manual interaction before moving forward in the pipeline. -You can do this straight from the pipeline graph. Just click the play button +You can do this straight from the pipeline graph. Just select the play button to execute that particular job. For example, your pipeline can start automatically, but require a manual action to @@ -259,8 +259,8 @@ In the example below, the `production` stage has a job with a manual action: > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/27188) in GitLab 11.11. -Multiple manual actions in a single stage can be started at the same time using the "Play all manual" button. -After you click this button, each individual manual action is triggered and refreshed +Multiple manual actions in a single stage can be started at the same time using the "Play all manual" +After you select this action, each individual manual action is triggered and refreshed to an updated status. This functionality is only available: @@ -283,9 +283,9 @@ pipelines. Users with the Owner role for a project can delete a pipeline by clicking on the pipeline in the **CI/CD > Pipelines** to get to the **Pipeline Details** -page, then using the **Delete** button. +page, then selecting **Delete**. - + WARNING: Deleting a pipeline expires all pipeline caches, and deletes all related objects, @@ -314,7 +314,7 @@ sensitive information like deployment credentials and tokens. **Runners** marked as **protected** can run jobs only on protected branches, preventing untrusted code from executing on the protected runner and preserving deployment keys and other credentials from being unintentionally -accessed. In order to ensure that jobs intended to be executed on protected +accessed. To ensure that jobs intended to be executed on protected runners do not use regular runners, they must be tagged accordingly. ### How pipeline duration is calculated @@ -385,6 +385,12 @@ You can group the jobs by: [Multi-project pipeline graphs](multi_project_pipelines.md#multi-project-pipeline-visualization) help you visualize the entire pipeline, including all cross-project inter-dependencies. **(PREMIUM)** +If a stage contains more than 100 jobs, only the first 100 jobs are listed in the +pipeline graph. The remaining jobs still run as normal. To see the jobs: + +- Select the pipeline, and the jobs are listed on the right side of the pipeline details page. +- On the left sidebar, select **CI/CD > Jobs**. + ### View job dependencies in the pipeline graph > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/298973) in GitLab 13.12. @@ -428,7 +434,7 @@ fix it. Pipeline mini graphs only display jobs by stage. -Stages in pipeline mini graphs are collapsible. Hover your mouse over them and click to expand their jobs. +Stages in pipeline mini graphs are expandable. Hover your mouse over each stage to see the name and status, and select a stage to expand its jobs list. | Mini graph | Mini graph expanded | |:-------------------------------------------------------------|:---------------------------------------------------------------| diff --git a/doc/ci/pipelines/merge_request_pipelines.md b/doc/ci/pipelines/merge_request_pipelines.md index dcc3e7e6919..d80b745e6bc 100644 --- a/doc/ci/pipelines/merge_request_pipelines.md +++ b/doc/ci/pipelines/merge_request_pipelines.md @@ -41,8 +41,10 @@ Both of these types of pipelines can appear on the **Pipelines** tab of a merge The three types of merge request pipelines are: - Merge request pipelines, which run on the changes in the merge request's - source branch. These pipelines display a `detached` label to indicate that the + source branch. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/352939) + in GitLab 14.9, these pipelines display a `merge request` label to indicate that the pipeline ran only on the contents of the source branch, ignoring the target branch. + In GitLab 14.8 and earlier, the label is `detached`. - [Merged results pipelines](merged_results_pipelines.md), which run on the result of combining the source branch's changes with the target branch. - [Merge trains](merge_trains.md), which run when merging multiple merge requests diff --git a/doc/ci/pipelines/merge_trains.md b/doc/ci/pipelines/merge_trains.md index ffcce06cfbd..12ea3a70536 100644 --- a/doc/ci/pipelines/merge_trains.md +++ b/doc/ci/pipelines/merge_trains.md @@ -201,6 +201,10 @@ the merged result is out of date and the pipeline can't be retried. Instead, you should [add the merge request to the train](#add-a-merge-request-to-a-merge-train) again, which triggers a new pipeline. +If a job only fails intermittently, you can try using the [`retry`](../yaml/index.md#retry) +keyword in the `.gitlab-ci.yml` file to have the job retried before the pipeline completes. +If it succeeds after a retry, the merge request is not removed from the merge train. + ### Unable to add to merge train with message "The pipeline for this merge request failed." Sometimes the **Start/Add to merge train** button is not available and the merge request says, diff --git a/doc/ci/pipelines/merged_results_pipelines.md b/doc/ci/pipelines/merged_results_pipelines.md index 4794107cc87..7df9ea3f72f 100644 --- a/doc/ci/pipelines/merged_results_pipelines.md +++ b/doc/ci/pipelines/merged_results_pipelines.md @@ -24,7 +24,7 @@ Merged results pipelines can't run when: - The merge request is a [**Draft** merge request](../../user/project/merge_requests/drafts.md). In these cases, the pipeline runs as a [merge request pipeline](merge_request_pipelines.md) -and is labeled as `detached`. +and [is labeled as `merge request`](merge_request_pipelines.md#types-of-merge-request-pipelines). ## Prerequisites diff --git a/doc/ci/pipelines/pipelines_for_merged_results.md b/doc/ci/pipelines/pipelines_for_merged_results.md index 457f5ce9c30..0c3100a51f1 100644 --- a/doc/ci/pipelines/pipelines_for_merged_results.md +++ b/doc/ci/pipelines/pipelines_for_merged_results.md @@ -6,4 +6,6 @@ remove_date: '2022-04-27' This document was moved to [another location](merged_results_pipelines.md). <!-- This redirect file can be deleted after 2022-04-27. --> -<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page --> +<!-- Redirects that point to other docs in the same project expire in three months. --> +<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. --> +<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html --> diff --git a/doc/ci/pipelines/schedules.md b/doc/ci/pipelines/schedules.md index fe9db3306cd..8813f3e1d59 100644 --- a/doc/ci/pipelines/schedules.md +++ b/doc/ci/pipelines/schedules.md @@ -6,142 +6,69 @@ disqus_identifier: 'https://docs.gitlab.com/ee/user/project/pipelines/schedules. type: reference, howto --- -# Pipeline schedules **(FREE)** +# Scheduled pipelines **(FREE)** -Pipelines are normally run based on certain conditions being met. For example, when a branch is pushed to repository. - -Pipeline schedules can be used to also run [pipelines](index.md) at specific intervals. For example: - -- Every month on the 22nd (cron example: `0 0 22 * *`) for a certain branch. -- Every month on the 2nd Monday (cron example: `0 0 * * 1#2`). -- Every other Sunday at 0900 hours (cron example: `0 9 * * sun%2`). -- Once every day (cron example: `0 0 * * *`). - -Schedule timing is configured with [cron notation](../../topics/cron/index.md). -You can use any cron value, but scheduled pipelines cannot run more frequently -than the instance's [maximum frequency for scheduled pipelines](#advanced-configuration). - -In addition to using the GitLab UI, pipeline schedules can be maintained using the -[Pipeline schedules API](../../api/pipeline_schedules.md). +Use scheduled pipelines to run GitLab CI/CD [pipelines](index.md) at regular intervals. ## Prerequisites -In order for a scheduled pipeline to be created successfully: - -- The schedule owner must have [permissions](../../user/permissions.md) to merge into the target branch. -- The pipeline configuration must be valid. - -Otherwise the pipeline is not created. - -## Configuring pipeline schedules - -To schedule a pipeline for project: - -1. Navigate to the project's **CI/CD > Schedules** page. -1. Click the **New schedule** button. -1. Fill in the **Schedule a new pipeline** form. -1. Click the **Save pipeline schedule** button. - - - -NOTE: -Pipelines execution [timing is dependent](#advanced-configuration) on Sidekiq's own schedule. - -In the **Schedules** index page you can see a list of the pipelines that are -scheduled to run. The next run is automatically calculated by the server GitLab -is installed on. - - - -### Using variables - -You can pass any number of arbitrary variables. They are available in -GitLab CI/CD so that they can be used in your [`.gitlab-ci.yml` file](../../ci/yaml/index.md). - - - -### Using `rules` - -To configure a job to be executed only when the pipeline has been -scheduled, use the [`rules`](../yaml/index.md#rules) keyword. - -In this example, `make world` runs in scheduled pipelines, and `make build` -runs in branch and tag pipelines: - -```yaml -job:on-schedule: - rules: - - if: $CI_PIPELINE_SOURCE == "schedule" - script: - - make world - -job: - rules: - - if: $CI_PIPELINE_SOURCE == "push" - script: - - make build -``` - -### Advanced configuration **(FREE SELF)** - -Scheduled pipelines can be configured with any [cron value](../../topics/cron/index.md), -but they do not always run exactly when scheduled. An internal process, called the -_pipeline schedule worker_, queues all the scheduled pipelines, but does not -run continuously. The worker runs on its own schedule, and scheduled pipelines that -are ready to start are only queued the next time the worker runs. Scheduled pipelines -can't run more frequently than the worker. - -The default frequency of the pipeline schedule worker is `3-59/10 * * * *` (every ten minutes, -starting with `0:03`, `0:13`, `0:23`, and so on). The default frequency for GitLab.com -is listed in the [GitLab.com settings](../../user/gitlab_com/index.md#gitlab-cicd). - -To change the frequency of the pipeline schedule worker: - -1. Edit the `gitlab_rails['pipeline_schedule_worker_cron']` value in your instance's `gitlab.rb` file. -1. [Reconfigure GitLab](../../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect. - -For example, to set the maximum frequency of pipelines to twice a day, set `pipeline_schedule_worker_cron` -to a cron value of `0 */12 * * *` (`00:00` and `12:00` every day). +For a scheduled pipeline to run: -## Working with scheduled pipelines +- The schedule owner must have the Developer role. For pipelines on protected branches, + the schedule owner must be [allowed to merge](../../user/project/protected_branches.md#configure-a-protected-branch) + to the branch. +- The [CI/CD configuration](../yaml/index.md) must be valid. -After configuration, GitLab supports many functions for working with scheduled pipelines. +Otherwise, the pipeline is not created. No error message is displayed. -### Running manually +## Add a pipeline schedule -> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/15700) in GitLab 10.4. +> Scheduled pipelines for tags [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/23292) in GitLab 14.9. -To trigger a pipeline schedule manually, click the "Play" button: +To add a pipeline schedule: - +1. On the top bar, select **Menu > Projects** and find your project. +1. On the left sidebar, select **CI/CD > Schedules**. +1. Select **New schedule** and fill in the form. + - **Interval Pattern**: Select one of the preconfigured intervals, or enter a custom + interval in [cron notation](../../topics/cron/index.md). You can use any cron value, + but scheduled pipelines cannot run more frequently than the instance's + [maximum scheduled pipeline frequency](../../administration/cicd.md#change-maximum-scheduled-pipeline-frequency). + - **Target branch or tag**: Select the branch or tag for the pipeline. + - **Variables**: Add any number of [CI/CD variables](../variables/index.md) to the schedule. + These variables are available only when the scheduled pipeline runs, + and not in any other pipeline run. -This schedules a background job to run the pipeline schedule. A flash -message provides a link to the CI/CD Pipeline index page. +## Run manually -NOTE: -To help avoid abuse, users are rate limited to triggering a pipeline once per -minute. +To trigger a pipeline schedule manually, so that it runs immediately instead of +the next scheduled time: -### Taking ownership +1. On the top bar, select **Menu > Projects** and find your project. +1. On the left sidebar, select **CI/CD > Schedules**. +1. On the right of the list, for + the pipeline you want to run, select **Play** (**{play}**). -Pipelines are executed as a user, who owns a schedule. This influences what projects and other resources the pipeline has access to. +You can manually run scheduled pipelines once per minute. -If a user does not own a pipeline, you can take ownership by clicking the **Take ownership** button. -The next time a pipeline is scheduled, your credentials are used. +## Take ownership - +Scheduled pipelines execute with the permissions of the user +who owns the schedule. The pipeline has access to the same resources as the pipeline owner, +including [protected environments](../environments/protected_environments.md) and the +[CI/CD job token](../jobs/ci_job_token.md). -If the owner of a pipeline schedule cannot create -pipelines on the target branch, the schedule stops creating new -pipelines. +To take ownership of a pipeline created by a different user: -This can happen if, for example: +1. On the top bar, select **Menu > Projects** and find your project. +1. On the left sidebar, select **CI/CD > Schedules**. +1. On the right of the list, for + the pipeline you want to become owner of, select **Take ownership**. -- The owner is blocked or removed from the project. -- The target branch or tag is protected. +## Related topics -In this case, someone with sufficient privileges must take ownership of the -schedule. +- Pipeline schedules can be maintained by using the [Pipeline schedules API](../../api/pipeline_schedules.md). +- You can [control which jobs are added to scheduled pipelines](../jobs/job_control.md#run-jobs-for-scheduled-pipelines). <!-- ## Troubleshooting 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.  -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.  @@ -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: |
