릴리스 증거
GitLab v19.5Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
요약
릴리스를 만들 때마다 GitLab은 그 릴리스와 관련된 데이터의 스냅숏을 남깁니다. 릴리스 증거를 확인하려면 Releases 페이지의 Evidence collection 제목 아래에 나열된 JSON 파일 링크를 선택합니다.
릴리스를 만들 때마다 GitLab은 그 릴리스와 관련된 데이터의 스냅숏을 남깁니다. 이 데이터는 JSON 파일로 저장되며 릴리스 증거라고 부릅니다. 이 기능에는 외부 감사 같은 내부 절차를 뒷받침하기 위해 테스트 아티팩트, 연결된 마일스톤, 버전이 일치하는 패키지가 포함됩니다.
릴리스 증거를 확인하려면 Releases 페이지의 Evidence collection 제목 아래에 나열된 JSON 파일 링크를 선택합니다.
API를 사용해 기존 릴리스의 릴리스 증거를 생성할 수도 있습니다. 그래서 하나의 릴리스가 여러 개의 릴리스 증거 스냅숏을 가질 수 있습니다. 릴리스 증거와 그 세부 정보는 Releases 페이지에서 확인할 수 있습니다.
이슈 트래커가 비활성화돼 있으면 릴리스 증거를 내려받을 수 없습니다.
릴리스 증거 객체의 예는 다음과 같습니다:
{
"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",
"description": "milestone description",
},
{
"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",
"description": "milestone description",
}
],
"packages": [
{
"id": 1,
"name": "my-package",
"version": "4.0",
"package_type": "generic",
"created_at": "2019-06-20 10:00:00 UTC"
}
],
"report_artifacts": [
{
"url":"https://gitlab.example.com/root/project-name/-/jobs/111/artifacts/download"
}
]
}
}
패키지를 릴리스 증거로 포함#
히스토리
- GitLab 18.11에서 도입되었습니다.
릴리스를 만들면 GitLab은 프로젝트의
패키지 레지스트리에서 버전이 릴리스 태그와
일치하는 패키지를 자동으로 조회합니다. 일치하는 패키지는 릴리스 증거 JSON의
packages 키 아래에 포함됩니다.
버전 일치는 다음과 같이 동작합니다:
- 릴리스 태그에
v또는V접두사가 있으면(예:v1.0.0) 일치 판단 전에 접두사가 제거됩니다. 태그v1.0.0은 버전이1.0.0인 패키지와 일치합니다. - 릴리스 태그에 접두사가 없으면(예:
1.0.0) 그대로 일치 판단에 사용됩니다. - 표시 가능한 패키지만 포함됩니다. 삭제 대기 상태이거나 오류 상태인 패키지는 제외됩니다.
- 하나의 릴리스에 여러 패키지가 일치할 수 있습니다. 예를 들어 프로젝트가 버전
1.0.0으로 generic 패키지와 npm 패키지를 모두 게시했다면 두 패키지가 모두 증거에 포함됩니다.
증거의 각 패키지 항목에는 다음 필드가 들어 있습니다:
| 필드 | 설명 |
|---|---|
id |
패키지의 고유 ID입니다. |
name |
패키지의 이름입니다. |
version |
패키지의 버전 문자열입니다. |
package_type |
패키지의 유형입니다(예: generic, npm, maven). |
created_at |
패키지가 생성된 시각입니다. |
별도의 구성은 필요하지 않습니다. 프로젝트의 패키지 레지스트리에 릴리스 태그와 버전이 일치하는 패키지가 있으면 증거를 수집할 때 자동으로 포함됩니다.
릴리스 증거 수집#
릴리스를 만들면 릴리스 증거가 자동으로 수집됩니다. 다른 시점에 증거 수집을 시작하려면 API 호출을 사용합니다. 하나의 릴리스에 대해 릴리스 증거를 여러 번 수집할 수 있습니다.
증거 수집 스냅숏은 증거를 수집한 시각과 함께 Releases 페이지에 표시됩니다.
보고서 아티팩트를 릴리스 증거로 포함#
릴리스를 만들 때 마지막으로 실행된 파이프라인에 job 아티팩트가 포함돼 있으면, 해당 아티팩트가 릴리스 증거로 릴리스에 자동으로 포함됩니다.
job 아티팩트는 보통 만료되지만, 릴리스 증거에 포함된 아티팩트는 만료되지 않습니다.
job 아티팩트 수집을 활성화하려면 다음 두 가지를 모두 지정해야 합니다:
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
파이프라인이 성공적으로 실행되었다면, 릴리스를 만들 때 rspec.xml 파일이
릴리스 증거로 저장됩니다.
릴리스 증거 수집을 예약하면
증거를 수집하는 시점에 일부 아티팩트가 이미 만료돼 있을 수 있습니다. 이를 피하려면
artifacts:expire_in
키워드를 사용할 수 있습니다. 자세한 내용은 이슈 222351을 참고합니다.
릴리스 증거 수집 예약#
API에서는 다음과 같이 동작합니다:
- 미래 시점의
released_at날짜를 지정하면 릴리스가 Upcoming release가 되고 증거는 릴리스 날짜에 수집됩니다. 그 전에는 릴리스 증거를 수집할 수 없습니다. - 과거 시점의
released_at날짜를 지정하면 릴리스가 Historical release가 되고 증거는 수집되지 않습니다. released_at날짜를 지정하지 않으면 릴리스를 만든 날짜에 릴리스 증거가 수집됩니다.