REST APIの非推奨化
以下の非推奨を定期的に確認し、推奨される変更を加えてください。これらの非推奨は、多くの場合、API機能の改善を示しており、機能に新しいフィールドまたはエンドポイントを使用することを推奨しています。
一部の非推奨ではv5 REST APIについて言及されていますが、v5 REST APIの開発はアクティブではありません。GitLabは、REST APIのセマンティックバージョニングに従うことをコミットしているため、これらの変更をREST API v4内で行うことはありません。
geo_nodes APIエンドポイント
破壊的な変更関連イシューを参照してください。
geo_nodes APIエンドポイントは非推奨となり、geo_sitesに置き換えられました。これは、Geoデプロイの参照方法に関するグローバルな変更の一部です。ノードは、アプリケーション全体でサイトに名前が変更されました。両方のエンドポイントの機能は同じままです。
merged_by APIフィールド
破壊的な変更関連イシューを参照してください。
マージリクエストAPIのmerged_byフィールドは、単純なマージ以外の操作（自動マージの設定、マージトレインへの追加）を実行する際に、誰がマージリクエストをマージしたかをより正確に識別するmerge_userフィールドを優先して、非推奨になりました。
APIユーザーは、代わりに新しいmerge_userフィールドを使用することをお勧めします。merged_byフィールドは、GitLab REST APIのv5で削除されます。
merge_status APIフィールド
破壊的な変更関連イシューを参照してください。
マージリクエストAPIのmerge_statusフィールドは、マージリクエストが取り得るすべての潜在的なステータスをより正確に識別するdetailed_merge_statusフィールドを優先して、非推奨になりました。APIユーザーは、代わりに新しいdetailed_merge_statusフィールドを使用することをお勧めします。merge_statusフィールドは、GitLab REST APIのv5で削除されます。
User APIのprivate_profile属性のNull値
破壊的な変更関連イシューを参照してください。
APIを介してユーザーを作成および更新する場合、nullはprivate_profile属性の有効な値でしたが、内部的にデフォルト値に変換されていました。GitLab REST APIのv5では、nullはこのパラメータの有効な値ではなくなり、使用すると応答は400になります。この変更後、有効な値はtrueとfalseのみになります。
単一のマージリクエスト変更APIエンドポイント
破壊的な変更関連イシューを参照してください。
単一のマージリクエストからの変更を取得するためのエンドポイントは、マージリクエストの差分の一覧エンドポイントを優先して非推奨になりました。APIユーザーは、代わりに新しい差分エンドポイントに切り替えることをお勧めします。
changes from a single merge requestエンドポイントは、GitLab REST APIのv5で削除されます。
Managed Licenses APIエンドポイント
破壊的な変更関連イシューを参照してください。
特定のプロジェクトのすべての管理ライセンスを取得するためのエンドポイントは、ライセンス承認ポリシー機能を優先して非推奨になりました。
検出されたライセンスに基づいて承認を引き続き適用したい場合は、代わりに新しいライセンス承認ポリシーを作成することをおすすめします。
managed licensesエンドポイントは、GitLab REST APIのv5で削除されます。
マージリクエスト承認APIの承認者と承認者グループのフィールド
破壊的な変更関連イシューを参照してください。
プロジェクトの承認の設定を取得するためのエンドポイントは、approversとapproval_groupsの空の配列を返します。これらのフィールドは、マージリクエストのすべての承認ルールをリストするエンドポイントを優先して非推奨になりました。APIユーザーは、代わりにこのエンドポイントに切り替えることをお勧めします。
これらのフィールドは、GitLab REST APIのv5のget configurationエンドポイントから削除されます。
Runnerでのactiveの使用をpausedに置き換え
破壊的な変更関連イシューを参照してください。
GitLab GraphQL APIエンドポイントで出現するactive識別子は、GitLab 16.0で名前がpausedに変更されます。
- REST APIのv4では、
activeの代わりにpausedプロパティを使用できます - REST APIのv5では、この変更は
activeプロパティを受け取るか返すエンドポイントに影響します（以下に示すエンドポイントなど）:GET /runnersGET /runners/allGET /runners/:id/PUT /runners/:idPUT --form "active=false" /runners/:runner_idGET /projects/:id/runners/POST /projects/:id/runnersGET /groups/:id/runners
GitLab Runnerの16.0リリースでは、runnerを登録する際にpausedプロパティの使用を開始します。
Runnerステータスはpausedを返しません
破壊的な変更関連イシューを参照してください。
今後のREST API v5では、GitLab Runnerのエンドポイントもpausedまたはactiveを返しません。
Runnerのステータスは、online、offline、not_connectedなど、Runnerの接続ステータスのみに関連します。ステータスpausedまたはactiveは表示されなくなります。
Runnerがpausedかどうかを確認する場合、APIユーザーは、代わりにブール属性pausedがtrueであるかどうかを確認することをおすすめします。Runnerがactiveかどうかを確認する場合は、pausedがfalseであるかどうかを確認します。
Runnerはip_addressを返しません
破壊的な変更関連イシューを参照してください。
GitLab 17.0では、Runner APIは、runnerのip_addressの代わりに""を返します。REST APIのv5では、このフィールドは削除されます。
default_branch_protection APIフィールド
破壊的な変更関連イシューを参照してください。
default_branch_protectionフィールドは、次のAPIでGitLab 17.0で非推奨になりました:
代わりにdefault_branch_protection_defaultsフィールドを使用する必要があります。これにより、デフォルトのブランチ保護をより細かく制御できます。
default_branch_protectionフィールドは、GitLab REST APIのv5で削除されます。
require_password_to_approve APIフィールド
require_password_to_approveは、GitLab 16.9で非推奨になりました。代わりにrequire_reauthentication_to_approveフィールドを使用します。両方のフィールドに値を指定すると、require_reauthentication_to_approveフィールドが優先されます。
require_password_to_approveフィールドは、GitLab REST APIのv5で削除されます。
プロジェクトAPIエンドポイントを使用したプルミラーリング設定
破壊的な変更関連イシューを参照してください。
GitLab 17.6では、プロジェクトAPIを使用したプルミラーリング設定は非推奨になりました。新しい設定とエンドポイントであるprojects/:id/mirror/pullに置き換えられます。
プロジェクトAPIを使用する以前の設定は、GitLab REST APIのv5で削除されます。
プロジェクトAPIエンドポイントのrestrict_user_defined_variablesパラメータ
GitLab 17.7では、Projects APIのrestrict_user_defined_variablesパラメータは、ci_pipeline_variables_minimum_override_roleのみを使用することを推奨しています。
restrict_user_defined_variables: falseと同じ動作をさせるには、ci_pipeline_variables_minimum_override_roleをdeveloperに設定します。