リリースエビデンス

プラン: Free、Premium、Ultimate
提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

リリースが作成されるたびに、GitLabは関連するデータのスナップショットを取得します。このデータはJSONファイルに保存され、リリースエビデンスと呼ばれます。この機能には、テストアーティファクト、リンクされたマイルストーン、および一致するパッケージが含まれており、外部監査のような内部プロセスを容易にします。

リリースエビデンスにアクセスするには、Releasesページで、エビデンス一覧の見出しの下に記載されている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は自動的にプロジェクトのパッケージレジストリをクエリして、リリースタグと一致するバージョンのパッケージを探します。一致するパッケージは、リリースエビデンスのJSONのpackagesキーの下に含まれます。

バージョンのマッチングは次のとおりです:

リリースタグにvまたはVプレフィックスがある場合（例: v1.0.0）、マッチングの前にプレフィックスは削除されます。タグv1.0.0はパッケージとバージョン1.0.0が一致します。
リリースタグにプレフィックスがない場合（例: 1.0.0）、直接マッチングされます。
表示可能なパッケージのみが含まれます。破棄待ちまたはエラー状態のパッケージは除外されます。
複数のパッケージが単一のリリースに一致する場合があります。たとえば、プロジェクトが汎用パッケージとNPMパッケージの両方をバージョン1.0.0で公開している場合、両方がエビデンスに含まれます。

エビデンス内の各パッケージエントリには、次のフィールドが含まれます:

フィールド	説明
`id`	パッケージの一意のID。
`name`	パッケージの名前。
`version`	パッケージのバージョン文字列。
`package_type`	パッケージのタイプ（例: `generic`、`npm`、`maven`）。
`created_at`	パッケージが作成されたタイムスタンプ。

追加の設定は必要ありません。プロジェクトのパッケージレジストリにリリースタグと一致するバージョンのパッケージが存在する限り、エビデンスが収集される際に自動的に含まれます。

リリースエビデンスを収集する

プラン: Premium、Ultimate
提供形態: GitLab Self-Managed、GitLab Dedicated

リリースが作成されると、リリースエビデンスは自動的に収集されます。それ以外のときにエビデンスの収集を開始するには、APIコールを使用します。1つのリリースに対して、リリースエビデンスを複数回収集できます。

エビデンス収集のスナップショットは、エビデンスが収集されたタイムスタンプとともに、Releasesページに表示されます。

レポートアーティファクトをリリースエビデンスとして含める

プラン: Ultimate
提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

リリースを作成する際、最後に実行されたパイプラインにジョブアーティファクトが含まれている場合、それらはリリースにリリースエビデンスとして自動的に含まれます。

ジョブアーティファクトは通常期限切れになりますが、リリースエビデンスに含まれるアーティファクトは期限切れになりません。

ジョブアーティファクトの収集を有効にするには、両方を指定する必要があります:

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の日付を指定した場合、そのリリースは過去のリリースとなり、エビデンスは収集されません。
released_atの日付を指定しない場合、リリースエビデンスはリリース作成日に収集されます。