@@ -88,7 +86,6 @@ release tag. When the `released_at` date and time has passed, the badge is autom
...
@@ -88,7 +86,6 @@ release tag. When the `released_at` date and time has passed, the badge is autom
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/26016) in GitLab 12.6. Asset link editing was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9427) in GitLab 12.10.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/26016) in GitLab 12.6. Asset link editing was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/9427) in GitLab 12.10.
NOTE: **Note:**
Only users with Developer permissions or higher can edit releases.
Only users with Developer permissions or higher can edit releases.
Read more about [Release permissions](../../../user/permissions.md#project-members-permissions).
Read more about [Release permissions](../../../user/permissions.md#project-members-permissions).
...
@@ -225,7 +222,6 @@ The release title can be customized using the **Release title** field when
...
@@ -225,7 +222,6 @@ The release title can be customized using the **Release title** field when
creating or editing a release. If no title is provided, the release's tag name
creating or editing a release. If no title is provided, the release's tag name
is used instead.
is used instead.
NOTE: **Note:**
Guest users of private projects are allowed to view the **Releases** page
Guest users of private projects are allowed to view the **Releases** page
but are _not_ allowed to view details about the Git repository (in particular,
but are _not_ allowed to view details about the Git repository (in particular,
tag names). Because of this, release titles are replaced with a generic
tag names). Because of this, release titles are replaced with a generic
...
@@ -254,7 +250,6 @@ Every release has a description. You can add any text you like, but we recommend
...
@@ -254,7 +250,6 @@ Every release has a description. You can add any text you like, but we recommend
including a changelog to describe the content of your release. This helps users
including a changelog to describe the content of your release. This helps users
quickly scan the differences between each release you publish.
quickly scan the differences between each release you publish.
NOTE: **Note:**
[Git's tagging messages](https://git-scm.com/book/en/v2/Git-Basics-Tagging) and
[Git's tagging messages](https://git-scm.com/book/en/v2/Git-Basics-Tagging) and
Release note descriptions are unrelated. Description supports [Markdown](../../markdown.md).
Release note descriptions are unrelated. Description supports [Markdown](../../markdown.md).
...
@@ -334,8 +329,7 @@ generate release evidence for an existing release. Because of this, each release
...
@@ -334,8 +329,7 @@ generate release evidence for an existing release. Because of this, each release
can have multiple release evidence snapshots. You can view the release evidence and
can have multiple release evidence snapshots. You can view the release evidence and
its details on the Releases page.
its details on the Releases page.
NOTE: **Note:**
When the issue tracker is disabled, release evidence [can't be downloaded](https://gitlab.com/gitlab-org/gitlab/-/issues/208397).
When the issue tracker is disabled, release evidence [cannot be downloaded](https://gitlab.com/gitlab-org/gitlab/-/issues/208397).
Here is an example of a release evidence object:
Here is an example of a release evidence object:
...
@@ -431,10 +425,13 @@ ruby:
...
@@ -431,10 +425,13 @@ ruby:
junit:rspec.xml
junit:rspec.xml
```
```
If the pipeline ran successfully, when you create your release, the `rspec.xml` file is saved as release evidence.
If the pipeline ran successfully, when you create your release, the `rspec.xml` file is saved as
release evidence.
NOTE: **Note:**
If you [schedule release evidence collection](#schedule-release-evidence-collection),
If you [schedule release evidence collection](#schedule-release-evidence-collection), some artifacts may already be expired by the time of evidence collection. To avoid this you can use the [`artifacts:expire_in`](../../../ci/yaml/README.md#artifactsexpire_in) keyword. Learn more in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/222351).
some artifacts may already be expired by the time of evidence collection. To avoid this you can use
the [`artifacts:expire_in`](../../../ci/yaml/README.md#artifactsexpire_in)
keyword. Learn more in [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/222351).