ジョブアーティファクトのトラブルシューティング（管理者向け）

ジョブアーティファクトを管理する際に、次の問題が発生する可能性があります。

ジョブアーティファクトがディスク容量を過剰に使用している

ジョブアーティファクトは、予想以上に早くディスク容量を消費する可能性があります。考えられる理由を以下に示します:

• ユーザーが、ジョブアーティファクトの有効期限を必要以上に長く設定している。
• 実行されるジョブの数、ひいては生成されるアーティファクトの数が、予想以上に多い。
• ジョブログが予想以上に大きく、時間の経過とともに蓄積されている。
• ファイルシステムは、アーティファクトのハウスキーピングによって空のディレクトリが残されるため、inodeを使い果たしてしまう可能性があります。孤立したアーティファクトファイルに対するRakeタスクは、これらを削除します。
• アーティファクトファイルがディスク上に残され、ハウスキーピングによって削除されない可能性があります。これらを削除するには、孤立したアーティファクトファイルに対するRakeタスクを実行します。このスクリプトは、空のディレクトリも削除するため、（前の理由を参照）常に実行する作業を見つけるはずです。
• unknownステータスのアーティファクトは、自動クリーンアップで処理されない可能性があります。ディスク容量を回復するために、これらのアーティファクトをチェックしてクリーンアップできます。
• 最新の成功ジョブから最新のアーティファクトを保持する機能が有効になっています。

これらのケースやその他のケースでは、ディスク容量の使用に最も責任のあるプロジェクトを特定し、どの種類のアーティファクトが最も容量を使用しているかを把握し、場合によっては、ジョブアーティファクトを手動で削除してディスク容量を回復します。

アーティファクトのハウスキーピング

アーティファクトのハウスキーピングとは、どのアーティファクトが有効期限切れで削除可能かを識別するプロセスです。

unknownステータスのアーティファクトを確認する

一部のアーティファクトのステータスがunknownになっているのは、ハウスキーピングシステムが正しいロックステータスを判別できないためです。これらのアーティファクトは、有効期限が切れても自動クリーンアップで処理されず、ディスク容量の過剰な使用につながる可能性があります。

インスタンスにunknownステータスのアーティファクトがあるかどうかを確認するには、次の手順に従います:

1. データベースコンソールを起動します:

   Linuxパッケージ（Omnibus）

   sudo gitlab-psql

   Helmチャート（Kubernetes）

   # Find the toolbox pod
   kubectl --namespace <namespace> get pods -lapp=toolbox
   # Connect to the PostgreSQL console
   kubectl exec -it <toolbox-pod-name> -- /srv/gitlab/bin/rails dbconsole --include-password --database main

   Docker

   sudo docker exec -it <container_name> /bin/bash
   gitlab-psql

   自己コンパイル（ソース）

   sudo -u git -H psql -d gitlabhq_production

2. 次のクエリを実行します:

   select expire_at, file_type, locked, count(*) from ci_job_artifacts
   where expire_at is not null and
   file_type != 3
   group by expire_at, file_type, locked having count(*) > 1;

ロックされたステータス2でレコードが返された場合、これらはunknownアーティファクトです。次に例を示します:

           expire_at           | file_type | locked | count
-------------------------------+-----------+--------+--------
 2021-06-21 22:00:00+00        |         1 |      2 |  73614
 2021-06-21 22:00:00+00        |         2 |      2 |  73614
 2021-06-21 22:00:00+00        |         4 |      2 |   3522
 2021-06-21 22:00:00+00        |         9 |      2 |     32
 2021-06-21 22:00:00+00        |        12 |      2 |    163

unknownアーティファクトがある場合は、有効期限を短く設定するか、手動で削除してディスク容量を回復できます。

unknownアーティファクトをクリーンアップする

unknownアーティファクトをクリーンアップするには、より短い有効期限を設定して、自動クリーンアッププロセスで処理できるようにします:

1. Railsコンソールを起動します。

2. unknownアーティファクトの有効期限を現在の時刻に設定します:

   # This marks unknown artifacts for immediate cleanup
   Ci::JobArtifact.where(locked: 2).update_all(artifacts_expire_at: Time.current)

自動ハウスキーピングプロセスは、次回の実行時にこれらのアーティファクトをクリーンアップします。

@finalアーティファクトがオブジェクトストレージから削除されない

GitLab 16.1以降、アーティファクトは、一時的な場所を最初に使用するのではなく、@finalディレクトリ内の最終ストレージの場所に直接アップロードされます。

GitLab 16.1および16.2の問題により、アーティファクトが有効期限切れになったときにオブジェクトストレージから削除されません。有効期限切れのアーティファクトのクリーンアッププロセスでは、@finalディレクトリからアーティファクトは削除されません。この問題はGitLab 16.3以降で修正されています。

GitLab 16.1または16.2をしばらく実行していたインスタンスの管理者は、アーティファクトによって使用されるオブジェクトストレージの増加を確認できる可能性があります。これらのアーティファクトを確認して削除するには、次の手順に従います。

ファイルの削除は、2段階のプロセスです:

1. どのファイルが孤立しているかを特定します。
2. 特定されたファイルをオブジェクトストレージから削除します。

孤立したジョブアーティファクトを一覧表示する

sudo gitlab-rake gitlab:cleanup:list_orphan_job_artifact_final_objects

docker exec -it <container-id> bash
gitlab-rake gitlab:cleanup:list_orphan_job_artifact_final_objects

sudo -u git -H bundle exec rake gitlab:cleanup:list_orphan_job_artifact_final_objects RAILS_ENV=production

# find the pod
kubectl get pods --namespace <namespace> -lapp=toolbox

# open the Rails console
kubectl exec -it -c toolbox <toolbox-pod-name> bash
gitlab-rake gitlab:cleanup:list_orphan_job_artifact_final_objects

Rakeタスクには、すべてのタイプのGitLabデプロイに適用される追加機能がいくつかあります:

• オブジェクトストレージのスキャンは中断できます。進行状況はRedisに記録され、これはその時点からアーティファクトのスキャンを再開するために使用されます。

• デフォルトでは、RakeタスクはCSVファイルを生成します。/opt/gitlab/embedded/service/gitlab-rails/tmp/orphan_job_artifact_final_objects.csv

• 環境変数を設定して、別のファイル名を指定します:

  # Packaged GitLab
  sudo su -
  FILENAME='custom_filename.csv' gitlab-rake gitlab:cleanup:list_orphan_job_artifact_final_objects

• 出力ファイルがすでに存在する場合（デフォルトまたは指定されたファイル）、ファイルにエントリが追加されます。

• 各行には、ファイルヘッダーなしで、コンマで区切られたフィールドobject_path,object_sizeが含まれています。次に例を示します:

  35/13/35135aaa6cc23891b40cb3f378c53a17a1127210ce60e125ccf03efcfdaec458/@final/1a/1a/5abfa4ec66f1cc3b681a4d430b8b04596cbd636f13cdff44277211778f26,201

孤立したジョブアーティファクトを削除する

sudo gitlab-rake gitlab:cleanup:delete_orphan_job_artifact_final_objects

docker exec -it <container-id> bash
gitlab-rake gitlab:cleanup:delete_orphan_job_artifact_final_objects

sudo -u git -H bundle exec rake gitlab:cleanup:delete_orphan_job_artifact_final_objects RAILS_ENV=production

# find the pod
kubectl get pods --namespace <namespace> -lapp=toolbox

# open the Rails console
kubectl exec -it -c toolbox <toolbox-pod-name> bash
gitlab-rake gitlab:cleanup:delete_orphan_job_artifact_final_objects

以下は、すべてのタイプのGitLabデプロイに適用されます:

• FILENAME変数を使用して入力ファイル名を指定します。デフォルトでは、スクリプトは以下を探します。/opt/gitlab/embedded/service/gitlab-rails/tmp/orphan_job_artifact_final_objects.csv
• スクリプトはファイルを削除すると、削除されたファイルを含むCSVファイルを出力します:

  • ファイルは入力ファイルと同じディレクトリにあります

  • ファイル名にはdeleted_from--というプレフィックスが付きます。例: deleted_from--orphan_job_artifact_final_objects.csv。

  • ファイルの行はobject_path,object_size,object_generation/versionです。以下に例を示します:

    35/13/35135aaa6cc23891b40cb3f378c53a17a1127210ce60e125ccf03efcfdaec458/@final/1a/1a/5abfa4ec66f1cc3b681a4d430b8b04596cbd636f13cdff44277211778f26,201,1711616743796587

特定の有効期限（または有効期限なし）を持つアーティファクトを含むプロジェクトとビルドを一覧表示する

Railsコンソールを使用すると、ジョブアーティファクトを持つプロジェクトを次のいずれかで見つけることができます:

• 有効期限の日付がありません。
• 有効期限が7日以上先の未来の日付。

アーティファクトの削除と同様に、次の時間の例を使用して、必要に応じて変更します:

• 7.days.from_now
• 10.days.from_now
• 2.weeks.from_now
• 3.months.from_now
• 1.year.from_now

次の各スクリプトは、.limit(50)で検索を50件の結果に制限しますが、必要に応じてこの数値を変更することもできます:

# Find builds & projects with artifacts that never expire
builds_with_artifacts_that_never_expire = Ci::Build.with_downloadable_artifacts.where(artifacts_expire_at: nil).limit(50)
builds_with_artifacts_that_never_expire.find_each do |build|
  puts "Build with id #{build.id} has artifacts that don't expire and belongs to project #{build.project.full_path}"
end

# Find builds & projects with artifacts that expire after 7 days from today
builds_with_artifacts_that_expire_in_a_week = Ci::Build.with_downloadable_artifacts.where('artifacts_expire_at > ?', 7.days.from_now).limit(50)
builds_with_artifacts_that_expire_in_a_week.find_each do |build|
  puts "Build with id #{build.id} has artifacts that expire at #{build.artifacts_expire_at} and belongs to project #{build.project.full_path}"
end

保存されているジョブアーティファクトの合計サイズでプロジェクトを一覧表示する

Railsコンソールで次のコードを実行して、保存されているジョブアーティファクトの合計サイズでソートされた上位20件のプロジェクトを一覧表示します:

include ActionView::Helpers::NumberHelper
ProjectStatistics.order(build_artifacts_size: :desc).limit(20).each do |s|
  puts "#{number_to_human_size(s.build_artifacts_size)} \t #{s.project.full_path}"
end

表示されるプロジェクトの数を変更するには、.limit(20)を必要な数に変更します。

単一プロジェクトで最大のアーティファクトを一覧表示する

Railsコンソールで次のコードを実行して、単一プロジェクトで最大の50個のジョブアーティファクトを一覧表示します:

include ActionView::Helpers::NumberHelper
project = Project.find_by_full_path('path/to/project')
Ci::JobArtifact.where(project: project).order(size: :desc).limit(50).map { |a| puts "ID: #{a.id} - #{a.file_type}: #{number_to_human_size(a.size)}" }

表示されるジョブアーティファクトの数を変更するには、.limit(50)を必要な数に変更します。

単一プロジェクト内のアーティファクトを一覧表示する

単一プロジェクトのアーティファクトを、アーティファクトサイズでソートして一覧表示します。出力には以下が含まれます:

• アーティファクトを作成したジョブのID
• アーティファクトサイズ
• アーティファクトファイルタイプ
• アーティファクト作成日
• アーティファクトのディスク上の場所

p = Project.find_by_id(<project_id>)
arts = Ci::JobArtifact.where(project: p)

list = arts.order(size: :desc).limit(50).each do |art|
    puts "Job ID: #{art.job_id} - Size: #{art.size}b - Type: #{art.file_type} - Created: #{art.created_at} - File loc: #{art.file}"
end

表示されるジョブアーティファクトの数を変更するには、limit(50)の数値を変更します。

古いビルドとアーティファクトを削除する

プロジェクトの古いアーティファクトを削除する

この手順では、ユーザーが保持することを選択したアーティファクトも消去します:

project = Project.find_by_full_path('path/to/project')
builds_with_artifacts =  project.builds.with_downloadable_artifacts
builds_with_artifacts.where("finished_at < ?", 1.year.ago).each_batch do |batch|
  batch.each do |build|
    Ci::JobArtifacts::DeleteService.new(build).execute
  end

  batch.update_all(artifacts_expire_at: Time.current)
end

古いアーティファクトをインスタンス全体で削除する

この手順では、ユーザーが保持することを選択したアーティファクトも消去します:

builds_with_artifacts = Ci::Build.with_downloadable_artifacts
builds_with_artifacts.where("finished_at < ?", 1.year.ago).each_batch do |batch|
  batch.each do |build|
    Ci::JobArtifacts::DeleteService.new(build).execute
  end

  batch.update_all(artifacts_expire_at: Time.current)
end

プロジェクトの古いジョブログとアーティファクトを削除する

project = Project.find_by_full_path('path/to/project')
builds =  project.builds
admin_user = User.find_by(username: 'username')
builds.where("finished_at < ?", 1.year.ago).each_batch do |batch|
  batch.each do |build|
    print "Ci::Build ID #{build.id}... "

    if build.erasable?
      Ci::BuildEraseService.new(build, admin_user).execute
      puts "Erased"
    else
      puts "Skipped (Nothing to erase or not erasable)"
    end
  end
end

古いジョブログとアーティファクトをインスタンス全体で削除する

builds = Ci::Build.all
admin_user = User.find_by(username: 'username')
builds.where("finished_at < ?", 1.year.ago).each_batch do |batch|
  batch.each do |build|
    print "Ci::Build ID #{build.id}... "

    if build.erasable?
      Ci::BuildEraseService.new(build, admin_user).execute
      puts "Erased"
    else
      puts "Skipped (Nothing to erase or not erasable)"
    end
  end
end

1.year.agoはRailsのActiveSupport::Durationメソッドです。まだ使用中のアーティファクトを誤って削除するリスクを軽減するために、長い期間から開始します。必要に応じて、3.months.ago、2.weeks.ago、または7.days.agoなど、短い期間で削除を再実行します。

メソッドerase_erasable_artifacts!は同期的であり、実行時にアーティファクトはすぐに削除されます。バックグラウンドキューによってスケジュールされることはありません。

アーティファクトを削除しても、ディスク容量はすぐには回復しません。

アーティファクトが削除されると、プロセスは2つのフェーズで発生します:

1. 削除準備完了としてマーク：Ci::JobArtifactレコードはデータベースから削除され、将来のpick_up_atタイムスタンプを持つCi::DeletedObjectレコードに変換されます。
2. ストレージから削除: アーティファクトファイルは、Ci::ScheduleDeleteObjectsCronWorkerワーカーがCi::DeletedObjectレコードを処理し、物理的にファイルを削除するまでディスク上に残ります。

削除は、システムリソースの過負荷を防ぐために意図的に制限されています:

• ワーカーは、1時間に1回、16分に実行されます。
• 最大20件の同時ジョブのバッチでオブジェクトを処理します。
• 削除された各オブジェクトにはpick_up_atタイムスタンプがあり、物理的な削除の対象となる時期を決定します

大規模な削除の場合、ディスク容量が完全に回復するまでに、物理的なクリーンアップにかなりの時間がかかることがあります。クリーンアップには、非常に大規模な削除の場合、数日かかることがあります。

ディスク容量を迅速に回復する必要がある場合は、アーティファクトの削除を迅速化できます。

アーティファクトの削除を迅速化する

大量のアーティファクトを削除した後にディスク容量を迅速に回復する必要がある場合は、標準のスケジューリング制限を回避するて、削除プロセスを迅速化できます。

# Set the pick_up_date to the current time on all artifacts
# This will mark them for immediate deletion
Ci::DeletedObject.update_all(pick_up_at: Time.current)

# Get the count of artifacts marked for deletion
Ci::DeletedObject.where("pick_up_at < ?", Time.current)

# Delete the artifacts from disk
while Ci::DeletedObject.where("pick_up_at < ?", Time.current).count > 0
  Ci::DeleteObjectsService.new.execute
  sleep(10)
end

# Get the count of artifacts marked for deletion (should now be zero)
Ci::DeletedObject.count

古いパイプラインを削除する

パイプラインを削除すると、そのパイプラインの以下も削除されます:

• ジョブアーティファクト
• ジョブログ
• ジョブメタデータ
• パイプラインメタデータ

ジョブとパイプラインのメタデータを削除すると、データベース内のCIテーブルのサイズを削減できます。CIテーブルは通常、インスタンスのデータベースで最大のテーブルです。

プロジェクトの古いパイプラインを削除する

project = Project.find_by_full_path('path/to/project')
user = User.find(1)
project.ci_pipelines.where("finished_at < ?", 1.year.ago).each_batch do |batch|
  batch.each do |pipeline|
    puts "Erasing pipeline #{pipeline.id}"
    Ci::DestroyPipelineService.new(pipeline.project, user).execute(pipeline)
  end
end

インスタンス全体の古いパイプラインを削除する

user = User.find(1)
Ci::Pipeline.where("finished_at < ?", 1.year.ago).each_batch do |batch|
  batch.each do |pipeline|
    puts "Erasing pipeline #{pipeline.id} for project #{pipeline.project_id}"
    Ci::DestroyPipelineService.new(pipeline.project, user).execute(pipeline)
  end
end

ジョブアーティファクトのアップロードがエラー500で失敗する

アーティファクトにオブジェクトストレージを使用しており、ジョブアーティファクトのアップロードが失敗した場合は、以下を確認してください:

• 次のようなエラーメッセージのジョブログ:

  WARNING: Uploading artifacts as "archive" to coordinator... failed id=12345 responseStatus=500 Internal Server Error status=500 token=abcd1234

• 次のようなエラーメッセージのワークホースログ:

  {"error":"MissingRegion: could not find region configuration","level":"error","msg":"error uploading S3 session","time":"2021-03-16T22:10:55-04:00"}

どちらの場合も、ジョブアーティファクトのオブジェクトストレージ設定にregionを追加する必要がある場合があります。

ジョブアーティファクトのアップロードが500 Internal Server Error (Missing file)で失敗する

フォルダーパスを含むバケット名は、統合されたオブジェクトストレージではサポートされていません。たとえばbucket/pathなどです。バケット名にパスが含まれている場合は、次のようなエラーが表示されることがあります:

WARNING: Uploading artifacts as "archive" to coordinator... POST https://gitlab.example.com/api/v4/jobs/job_id/artifacts?artifact_format=zip&artifact_type=archive&expire_in=1+day: 500 Internal Server Error (Missing file)
FATAL: invalid argument

統合されたオブジェクトストレージを使用しているときに、前のエラーが原因でジョブアーティファクトのアップロードが失敗する場合は、データタイプごとに個別のバケットを使用していることを確認してください。

Windowsマウントを使用している場合、ジョブアーティファクトのアップロードがFATAL: invalid argumentで失敗する

ジョブアーティファクトにCIFSでWindowsマウントを使用している場合、Runnerがアーティファクトをアップロードしようとすると、invalid argumentエラーが表示されることがあります:

WARNING: Uploading artifacts as "dotenv" to coordinator... POST https://<your-gitlab-instance>/api/v4/jobs/<JOB_ID>/artifacts: 500 Internal Server Error  id=1296 responseStatus=500 Internal Server Error status=500 token=*****
FATAL: invalid argument

この問題を回避するには、次のことを試してください:

• CIFSの代わりにext4マウントに切り替えます。
• CIFSファイルリースに関連する重要なバグ修正が多数含まれている、少なくともLinuxカーネル5.15にスケールします。
• 古いカーネルの場合は、ファイルリースを無効にするには、noleaseマウントオプションを使用します。

詳細については、調査の詳細を参照してください。

使用量クォータにアーティファクトストレージの使用量が正しく表示されない

場合によっては、アーティファクトストレージの使用量に、アーティファクトで使用される合計ストレージ容量の誤った値が表示されることがあります。インスタンス内のすべてのプロジェクトについてアーティファクトの使用状況の統計を再計算するには、このバックグラウンドスクリプトを実行します:

gitlab-rake gitlab:refresh_project_statistics_build_artifacts_size[https://example.com/path/file.csv]

https://example.com/path/file.csvファイルには、アーティファクトストレージの使用量を再計算するすべてのプロジェクトのプロジェクトIDを一覧表示する必要があります。ファイルには次の形式を使用します:

PROJECT_ID
1
2

スクリプトの実行中に、アーティファクトの使用量の値が0に変動する可能性があります。再計算後、使用量は再び期待どおりに表示されるはずです。

アーティファクトダウンロードフロー図

次のフロー図は、ジョブアーティファクトの仕組みを示しています。これらの図は、ジョブアーティファクトにオブジェクトストレージが設定されていることを前提としています。

プロキシダウンロードが無効

proxy_downloadがfalseに設定されている場合、GitLabは、署名済みURLを使用してオブジェクトストレージからアーティファクトをダウンロードするようにRunnerをリダイレクトします。通常、Runnerがソースから直接フェッチする方が高速であるため、通常、この設定が推奨されます。また、データがGitLabによってフェッチされ、Runnerに送信される必要がないため、帯域幅の使用量も削減されるはずです。ただし、オブジェクトストレージへの直接アクセスをRunnerに許可する必要があります。

リクエストフローは次のようになります:

%%{init: { "fontFamily": "GitLab Sans" }}%%
sequenceDiagram
    accTitle: Direct artifact download flow
    accDescr: Runner authenticates, gets redirected to object storage, and downloads artifacts directly.

    autonumber
    participant C as Runner
    participant O as Object Storage
    participant W as Workhorse
    participant R as Rails
    participant P as PostgreSQL
    C->>+W: GET /api/v4/jobs/:id/artifacts?direct_download=true
    Note over C,W: gitlab-ci-token@<CI_JOB_TOKEN>
    W-->+R: GET /api/v4/jobs/:id/artifacts?direct_download=true
    Note over W,R: gitlab-ci-token@<CI_JOB_TOKEN>
    R->>P: Look up job for CI_JOB_TOKEN
    R->>P: Find user who triggered job
    R->>R: Does user have :read_build access?
    alt Yes
      R->>W: Send 302 redirect to object storage presigned URL
      R->>C: 302 redirect
      C->>O: GET <presigned URL>
    else No
      R->>W: 401 Unauthorized
      W->>C: 401 Unauthorized
    end

この図の説明:

1. まず、RunnerはGET /api/v4/jobs/:id/artifactsエンドポイントを使用してジョブアーティファクトをフェッチしようとします。Runnerは、オブジェクトストレージから直接ダウンロードできることを示すために、最初の試行でdirect_download=trueクエリパラメータをアタッチします。直接ダウンロードは、FF_USE_DIRECT_DOWNLOAD機能フラグを介してRunner設定で無効にできます。このフラグは、trueにデフォルトで設定されています。

2. Runnerは、gitlab-ci-tokenのユーザー名と自動生成されたCI/CDジョブトークンをパスワードとして使用して、HTTP Basic認証でGETリクエストを送信します。このトークンはGitLabによって生成され、ジョブの開始時にRunnerに与えられます。

3. GETリクエストはGitLab APIに渡され、データベース内のトークンを検索し、トリガーしたユーザー名を検索します。

4. 手順5～8:

   • ユーザー名にビルドへのアクセス権がある場合、GitLabは事前署名付きURLを生成し、LocationをそのURLに設定して302リダイレクトを送信します。Runnerは302リダイレクトに従い、アーティファクトをダウンロードします。

   • ジョブが見つからない場合、またはユーザー名がジョブへのアクセス権を持っていない場合、APIは401 Unauthorizedを返します。

   Runnerは、次のHTTPステータスコードを受信した場合、再試行しません:

   • 200 OK
   • 401 Unauthorized
   • 403 Forbidden
   • 404 Not Found

   ただし、Runnerが500エラーなどの他のステータスコードを受信した場合、アーティファクトのダウンロードをさらに2回再試行し、各試行の間に1秒間スリープします。後続の試行では、direct_download=trueは省略されます。

プロキシダウンロードが有効

proxy_downloadがtrueの場合、Runnerがdirect_download=trueクエリパラメータを送信したとしても、GitLabは常にオブジェクトストレージからアーティファクトをフェッチし、データをRunnerに送信します。Runnerのネットワーキングアクセスが制限されている場合は、プロキシダウンロードが望ましい場合があります。

次の図は、プロキシダウンロードが無効になっている例と似ていますが、手順6～9では、GitLabは302リダイレクトをRunnerに送信しません。代わりに、GitLabはWorkhorseにデータのフェッチとRunnerへのストリーミングバックを指示します。Runnerの観点からは、/api/v4/jobs/:id/artifactsへの元のGETリクエストはバイナリデータを直接返します。

%%{init: { "fontFamily": "GitLab Sans" }}%%
sequenceDiagram
    accTitle: Proxied artifact download flow
    accDescr: Runner authenticates, GitLab fetches from object storage, and streams artifacts back.

    autonumber
    participant C as Runner
    participant O as Object Storage
    participant W as Workhorse
    participant R as Rails
    participant P as PostgreSQL
    C->>+W: GET /api/v4/jobs/:id/artifacts?direct_download=true
    Note over C,W: gitlab-ci-token@<CI_JOB_TOKEN>
    W-->+R: GET /api/v4/jobs/:id/artifacts?direct_download=true
    Note over W,R: gitlab-ci-token@<CI_JOB_TOKEN>
    R->>P: Look up job for CI_JOB_TOKEN
    R->>P: Find user who triggered job
    R->>R: Does user have :read_build access?
    alt Yes
      R->>W: SendURL with object storage presigned URL
      W->>O: GET <presigned URL>
      O->>W: <artifacts data>
      W->>C: <artifacts data>
    else No
      R->>W: 401 Unauthorized
      W->>C: 401 Unauthorized
    end

413 Request Entity Too Largeエラー

アーティファクトが大きすぎる場合、ジョブは次のエラーで失敗する可能性があります:

Uploading artifacts as "archive" to coordinator... too large archive <job-id> responseStatus=413 Request Entity Too Large status=413" at end of a build job on pipeline when trying to store artifacts to <object-storage>.

以下のことを行う必要があるかもしれません:

• 最大アーティファクトサイズを大きくします。
• プロキシサーバーとしてNGINXを使用している場合は、ファイルのアップロードサイズの制限を大きくします。この制限はデフォルトでは1MBに制限されています。NGINXの設定ファイルで、client-max-body-sizeの値を高く設定します。