141 lines
5 KiB
Markdown
141 lines
5 KiB
Markdown
|
---
|
||
|
stage: Govern
|
||
|
group: Compliance
|
||
|
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||
|
---
|
||
|
|
||
|
# Release evidence **(FREE)**
|
||
|
|
||
|
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/26019) in GitLab 12.6.
|
||
|
|
||
|
Each time a release is created, GitLab takes a snapshot of data that's related to it.
|
||
|
This data is saved in a JSON file and called *release evidence*. The feature
|
||
|
includes test artifacts and linked milestones to facilitate
|
||
|
internal processes, like external audits.
|
||
|
|
||
|
To access the release evidence, on the Releases page, select the link to the JSON file that's listed
|
||
|
under the **Evidence collection** heading.
|
||
|
|
||
|
You can also [use the API](../../../api/releases/index.md#collect-release-evidence) to
|
||
|
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
|
||
|
its details on the Releases page.
|
||
|
|
||
|
When the issue tracker is disabled, release evidence [can't be downloaded](https://gitlab.com/gitlab-org/gitlab/-/issues/208397).
|
||
|
|
||
|
Here is an example of a release evidence object:
|
||
|
|
||
|
```json
|
||
|
{
|
||
|
"release": {
|
||
|
"id": 5,
|
||
|
"tag_name": "v4.0",
|
||
|
"name": "New release",
|
||
|
"project": {
|
||
|
"id": 20,
|
||
|
"name": "Project name",
|
||
|
"created_at": "2019-04-14T11:12:13.940Z",
|
||
|
"description": "Project description"
|
||
|
},
|
||
|
"created_at": "2019-06-28 13:23:40 UTC",
|
||
|
"description": "Release description",
|
||
|
"milestones": [
|
||
|
{
|
||
|
"id": 11,
|
||
|
"title": "v4.0-rc1",
|
||
|
"state": "closed",
|
||
|
"due_date": "2019-05-12 12:00:00 UTC",
|
||
|
"created_at": "2019-04-17 15:45:12 UTC",
|
||
|
"issues": [
|
||
|
{
|
||
|
"id": 82,
|
||
|
"title": "The top-right popup is broken",
|
||
|
"author_name": "John Doe",
|
||
|
"author_email": "john@doe.com",
|
||
|
"state": "closed",
|
||
|
"due_date": "2019-05-10 12:00:00 UTC"
|
||
|
},
|
||
|
{
|
||
|
"id": 89,
|
||
|
"title": "The title of this page is misleading",
|
||
|
"author_name": "Jane Smith",
|
||
|
"author_email": "jane@smith.com",
|
||
|
"state": "closed",
|
||
|
"due_date": "nil"
|
||
|
}
|
||
|
]
|
||
|
},
|
||
|
{
|
||
|
"id": 12,
|
||
|
"title": "v4.0-rc2",
|
||
|
"state": "closed",
|
||
|
"due_date": "2019-05-30 18:30:00 UTC",
|
||
|
"created_at": "2019-04-17 15:45:12 UTC",
|
||
|
"issues": []
|
||
|
}
|
||
|
],
|
||
|
"report_artifacts": [
|
||
|
{
|
||
|
"url":"https://gitlab.example.com/root/project-name/-/jobs/111/artifacts/download"
|
||
|
}
|
||
|
]
|
||
|
}
|
||
|
}
|
||
|
```
|
||
|
|
||
|
## Collect release evidence **(PREMIUM SELF)**
|
||
|
|
||
|
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/199065) in GitLab 12.10.
|
||
|
|
||
|
When a release is created, release evidence is automatically collected. To initiate evidence collection any other time, use an [API call](../../../api/releases/index.md#collect-release-evidence). You can collect release evidence multiple times for one release.
|
||
|
|
||
|
Evidence collection snapshots are visible on the Releases page, along with the timestamp the evidence was collected.
|
||
|
|
||
|
## Include report artifacts as release evidence **(ULTIMATE)**
|
||
|
|
||
|
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32773) in GitLab 13.2.
|
||
|
|
||
|
When you create a release, if [job artifacts](../../../ci/yaml/index.md#artifactsreports) are included in the last pipeline that ran, they are automatically included in the release as release evidence.
|
||
|
|
||
|
Although job artifacts normally expire, artifacts included in release evidence do not expire.
|
||
|
|
||
|
To enable job artifact collection you must specify both:
|
||
|
|
||
|
1. [`artifacts:paths`](../../../ci/yaml/index.md#artifactspaths)
|
||
|
1. [`artifacts:reports`](../../../ci/yaml/index.md#artifactsreports)
|
||
|
|
||
|
```yaml
|
||
|
ruby:
|
||
|
script:
|
||
|
- gem install bundler
|
||
|
- bundle install
|
||
|
- bundle exec rspec --format progress --format RspecJunitFormatter --out rspec.xml
|
||
|
artifacts:
|
||
|
paths:
|
||
|
- rspec.xml
|
||
|
reports:
|
||
|
junit: rspec.xml
|
||
|
```
|
||
|
|
||
|
If the pipeline ran successfully, when you create your release, the `rspec.xml` file is saved as
|
||
|
release evidence.
|
||
|
|
||
|
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/index.md#artifactsexpire_in)
|
||
|
keyword. For more information, see [issue 222351](https://gitlab.com/gitlab-org/gitlab/-/issues/222351).
|
||
|
|
||
|
## Schedule release evidence collection
|
||
|
|
||
|
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/23697) in GitLab 12.8.
|
||
|
|
||
|
In the API:
|
||
|
|
||
|
- If you specify a future `released_at` date, the release becomes an **Upcoming release**
|
||
|
and the evidence is collected on the date of the release. You cannot collect
|
||
|
release evidence before then.
|
||
|
- If you specify a past `released_at` date, the release becomes an **Historical
|
||
|
release** and no evidence is collected.
|
||
|
- If you do not specify a `released_at` date, release evidence is collected on the
|
||
|
date the release is created.
|