GitLab：リソース待ちのジョブ
resource_group のあるジョブは、そのグループのリソースが空いているときだけ動きます。リソースグループのリソースは1つなので、そのグループのジョブはプロジェクトのすべてのパイプラインを通して1度に1つしか動きません。順番が来るまでジョブの状態は waiting_for_resource で、ジョブの画面には次の文が出ます。リソースを持っているジョブがあれば、View job currently using resource のボタンもつきます（GitLab のソース lib/gitlab/ci/status/processable/waiting_for_resource.rb・2026年10月28日に読んだもの）：
This job is waiting for resource: production
ジョブがリソースを取る時と返す時
- 動ける状態になったジョブは、
pendingではなくwaiting_for_resourceになります。手動のジョブを誰かが実行したとき、時間を置くジョブの時間が来たときも同じです（app/models/ci/processable.rb）。 - リソースを取るのは
pendingに進むとき、つまりランナーが拾う前で、pending の間も動いている間も持ち続けます。返すのは終わったとき（success・failed・canceled・skipped）だけです。リソースを持ったままランナーを待っているジョブがあると、グループのほかのジョブもみな待ちます。 resource_groupとtrigger:strategyのある起動のジョブは、下流のパイプラインが終わるまでリソースを持ちます。- GitLab は次のジョブにリソースを渡す前に、終わってから5分より経ったのにリソースを持ったままのジョブから取り戻します（
app/models/ci/resource_group.rbのstale_processables）。
次にどのジョブが動くか：処理の順
unordered（既定）：リソースを待っているジョブのどれか。oldest_first：いちばん古いパイプラインのジョブから。まだ動ける状態でないジョブ（createdやscheduled）も数えます。古いパイプラインのジョブが、たとえば前の段が終わらずにcreatedのままだと、新しいパイプラインのジョブはみな待ちます。newest_first：同じ決まりで、いちばん新しいパイプラインから。newest_ready_first：リソースを待っているジョブのうち、いちばん新しいもの。
処理の順を変えられるのは API だけです（リソースグループの更新の process_mode）。Prevent outdated deployment jobs が有効なら、最新のデプロイより古いデプロイのジョブは、順番が来たときに「The deployment job is older than the latest deployment, and therefore failed.」で失敗します（app/services/ci/resource_groups/assign_resource_from_resource_group_service.rb）。
リソースを使っているジョブの見つけ方
- ジョブの画面：View job currently using resource。ボタンが無ければ、リソースを持っているジョブはありません。
- REST API：
GET /projects/:id/resource_groupsがグループと処理の順の一覧、current_job（GitLab 18.6 以降）がリソースを使っているジョブ、upcoming_jobsが順番を待つジョブです。グループの名前は URL エンコードしてパスに入れます。 - GraphQL：待っているジョブの
detailedStatus { action { buttonTitle path } }が、リソースを使っているジョブのページです。GitLab の画面に出ない起動のジョブでも使えます。
curl -H "PRIVATE-TOKEN: your-token" "https://gitlab.com/api/v4/projects/group%2Fproject/resource_groups/production/current_job"
curl -H "PRIVATE-TOKEN: your-token" "https://gitlab.com/api/v4/projects/group%2Fproject/resource_groups/production/upcoming_jobs"
query {
project(fullPath: "group/project") {
job(id: "gid://gitlab/Ci::Build/123") { status detailedStatus { action { buttonTitle path } } }
}
}
どうするか
- リソースを使っているジョブが running か pending：GitLab の決まりどおりです。終わるのを待ちます。pending のままなら、ランナーが拾っていません。GitLab が詰まったとして落とすジョブへ。
- そのジョブが
createdで、処理の順がoldest_firstかnewest_first：これも決まりどおりです。そのパイプラインを開き、止めている段やジョブを探します。 - リソースを使っているジョブが無い：
upcoming_jobsを読みます。oldest_firstで、先頭のジョブがもう動かさなくてよい古いパイプラインのものなら、そのパイプラインかジョブを取り消し、必要なら次の分も同じようにします。 - 子パイプラインが親と同じリソースグループを使う：
oldest_firstだと、子は親のデプロイのジョブを待ち、親のジョブは子を待ちます。代わりに親の起動のジョブにresource_groupを置きます（行き詰まりを避ける）。 - パイプラインの多いプロジェクトや子パイプラインの多い設定で、まだ止まる：GitLab は既知の競合を挙げています（競合）。その回避の手は、新しいパイプラインを始めるか、同じリソースグループの終わったジョブを再実行することです。
IntelliJ IDEA で GitLab のパイプラインを見るなら
Lesstep の Pipeline Inbox for GitLab CI は、JetBrains IDE（2024.1 以降）のプラグインです。GitLab のプロジェクトのパイプラインを、ジョブを段ごとに並べて一覧にします。リソースを待っているジョブは「リソース待ち」と出し、GitLab が返せばリソースを使っているジョブの番号も添えて（detailedStatus.action）、ジョブが動くまでパイプラインを読み直し続けます。1.0.21 より前は、どのジョブがリソースを使っているかは出しませんでした。見るのは無料、再実行・取り消し・実行は Pro（月 US$1.50・30日間の無料試用つき）です。画面は日本語です。
GITLAB は GitLab Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitLab Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。
ほかに：GitLab のジョブが詰まった・時間切れで落とされた · GitLab の「You are not authorized to run this manual job」 · GitLab のパイプラインやジョブの断り（400・403・409・429） · GitLab のパイプラインがジョブ0件で失敗 · GitLab のジョブのログが見えない・空 · JetBrains の IDE で GitLab のパイプラインを見る · English