翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
GitLab の接続
GitLab 統合により、 AWS DevOps Agent は GitLab Pipelines からのデプロイをモニタリングし、インシデント対応中に因果調査を通知できます。この統合は、GitLab のアカウントレベルの登録と、特定のプロジェクトを個々のエージェントスペースに接続するという 2 つのステップのプロセスに従います。
GitLab の登録 (アカウントレベル)
GitLab は AWS アカウントレベルで登録され、そのアカウントのすべてのエージェントスペース間で共有されます。各登録は、1 人の GitLab ユーザーまたは 1 つの GitLab グループにリンクされます。
ステップ 1: パイプラインプロバイダーに移動する
AWS マネジメントコンソールにサインインする
AWS DevOps エージェントコンソールに移動する
機能プロバイダーページに移動する (サイドナビゲーションからアクセス可能)
Pipeline の「利用可能なプロバイダー」セクションで GitLab を検索し、登録を選択します
ステップ 2: GitLab 接続を設定する
GitLab 登録ページで、以下を設定します。
接続タイプ – 人として接続するかグループとして接続するかを選択します。
Personal (デフォルト) – ユーザー名とプロファイルを持つ個々の GitLab ユーザーアカウント
グループ – GitLab では、グループを使用して 1 つ以上の関連プロジェクトを同時に管理します。
GitLab インスタンスタイプ – 接続先の GitLab インスタンスのタイプを選択します。
GitLab.com (デフォルト) – パブリック GitLab サービス
GitLab セルフマネージド – GitLab セルフホストエンドポイントの使用チェックボックスをオンにし、GitLab インスタンスへの URL を指定します。
GitLab セルフマネージドのプライベート接続
プライベート接続を使用してエンドポイントに接続する – GitLab セルフマネージドインスタンスがパブリックインターネット経由で到達できない場合は、このオプションを選択して、 AWS DevOps Agent が VPC へのプライベート接続を介してエンドポイントに到達できるようにします。GitLab を登録する前にプライベート接続を作成し、ここで既存の接続を選択します。詳細については、「プライベートにホストされたツールへの接続」を参照してください。
アクセストークン – GitLab 個人用アクセストークンを提供します。
別のブラウザタブで、GitLab アカウントにログインします。
ユーザー設定に移動し、アクセストークンを選択する
次のアクセス許可を持つ新しい個人用アクセストークンを作成します。
read_repository– リポジトリコンテンツにアクセスするために必要ですread_virtual_registry– 仮想レジストリ情報にアクセスするために必要ですread_registry– レジストリ情報にアクセスするために必要ですapi– 読み取りおよび書き込み API アクセスに必要ですself_rotate- トークンのローテーションに必要です。この機能は現在 AWS DevOps エージェントではサポートされていませんが、後日サポートされます。これで を追加すると、今後新しいトークンを作成する必要がなくなります。
トークンの有効期限を現在の日付から最大 365 日に設定します。
生成されたトークンをコピーする
AWS DevOps エージェントコンソールに戻る
トークンを「アクセストークン」フィールドに貼り付けます。
ステップ 3: 登録を完了する
(オプション) タグ – 組織の目的で GitLab 登録に AWS タグを追加します。
Next を選択して設定を確認し、Submit を選択して GitLab 登録プロセスを完了します。システムはアクセストークンを検証し、接続を確立します。
エージェントスペースへのプロジェクトの接続
アカウントレベルで GitLab を登録したら、特定のプロジェクトを個々のエージェントスペースに接続できます。
AWS DevOps エージェントコンソールで、エージェントスペースを選択します。
機能タブに移動する
パイプラインセクションで、追加 を選択します。
利用可能なプロバイダーのリストから GitLab を選択する
使用するプロジェクトを含む GitLab 登録を選択します。
エージェントスペースに関連する GitLab プロジェクトを選択する
[保存] を選択します。
AWS DevOps Agent は、GitLab Pipelines からのデプロイについてこれらのプロジェクトをモニタリングし、因果調査を通知します。1 つのエージェントスペースで、複数の登録のプロジェクトを使用できます。別の登録からプロジェクトを追加するには、以下の手順を繰り返します。
コードレビューと自動テストの設定
GitLab 接続ステップでプロジェクトを選択すると、コードレビューと自動テストセクションに自動的に追加されます。このセクションでは、 リリース準備状況コードレビューおよび自動テスト機能を自動的にトリガーするプロジェクトを設定します。
コードレビューと自動テストの設定には以下が含まれます。
機能 — 各プロジェクトのコードレビューと自動テスト機能を選択します。このセクションでは、プロジェクトごとに 2 つの設定を提供します。
自動トリガー変更レビュー — プロジェクトで有効にすると、DevOps Agent はマージリクエストがオープンまたは更新リリース準備状況コードレビューされるたびに を自動的に実行します。レビューの結果は、マージリクエストにインラインコメントとして表示されます。これは、接続されているすべてのプロジェクトでデフォルトで有効になっています。
自動検証テスト — プロジェクトで有効にすると、DevOps Agent はコードレビュー中にマネージド検証環境でコード変更を構築、実行、テストします。これにより、静的分析以外の機能検証が可能になります。詳細については、「自動検証テスト」を参照してください。これは、接続されているすべてのプロジェクトでデフォルトで有効になっています。
プロジェクトリスト — 接続ステップ中に選択したすべてのプロジェクトを表示します。検索フィールドを使用して、プロジェクトを名前でフィルタリングします。各プロジェクトには、両方の機能に対して独立したチェックボックスがあります。
ランタイムロール (オプション) — 選択したプロジェクトで自動機能を実行するために DevOps Agent が引き受ける IAM ロールを選択します。このロールは、プライベートパッケージレジストリやアーティファクトストレージシステムなど、ビルド中に必要な内部サービスにアクセスするときに使用されます。プライマリエージェントロールとは異なるロールを使用することをお勧めします。
自動レビューを設定するには:
プロジェクトを接続したら、GitLab 統合設定のコードレビューと自動テストセクションに移動します。
プロジェクトごとに、自動マージリクエストのレビューが必要かどうかに応じて、自動トリガー変更レビュー機能を有効または無効にします。
マネージド検証環境で自動検証テストを行うかどうかに応じて、プロジェクトごとに自動検証テスト機能を有効または無効にします。
必要に応じて、選択したプロジェクトで自動機能を実行するときに DevOps Agent が引き受けるランタイムロールドロップダウンから IAM ロールを選択します。
保存を選択して設定を適用します。
設定すると、自動トリガー変更レビューが有効になっているプロジェクト内の新しいマージリクエストによって、リリース準備状況コードレビューが自動的にトリガーされます。自動検証テストも有効になっている場合、レビューには検証環境での機能検証が含まれます。コードレビューの詳細については、「」を参照してくださいリリース準備状況コードレビュー。
詳細設定: トリガーフィルター
デフォルトでは、自動トリガー変更レビューが有効になっているプロジェクトは、任意のターゲットブランチで、該当するすべてのマージリクエストイベントに対してリリース準備状況コードレビューを実行します。高度な設定を使用して、各プロジェクトで自動レビューが実行されるタイミングを正確に制御するトリガーフィルターを追加します。
各フィルターは、次の 2 つの条件を組み合わせたフィルターグループです。
ターゲットブランチ (必須) — 正規表現として入力された 1 つ以上のブランチ名またはパターン (例:
mainまたはrelease/.*)。レビューは、マージリクエストのターゲットブランチがこれらのパターンのいずれかと一致する場合にのみトリガーされます。トリガーイベント (オプション) — レビューをトリガーするマージリクエストイベント: レビューの準備ができたマージリクエストまたはドラフト済みのマージリクエスト。該当するすべてのイベントと一致するように、この値は空のままにします。
フィルターグループ内では、すべての条件が (AND) と一致する必要があります。複数のフィルターグループを追加でき、いずれかのグループが一致 (OR) するとレビューがトリガーされます。
トリガーフィルターを設定するには:
接続フローで詳細設定セクションを開きます。(既存の接続のフィルターを変更するには、パイプラインセクションで接続を選択し、編集を選択し、詳細設定を開きます)。
設定するプロジェクトを検索し、変更レビュータブを選択します。
フィルターグループを追加を選択し、グループの条件を定義します。
ターゲットブランチで、ブランチ名またはパターンを入力し、Enter キーまたは Add キーを選択します。繰り返してパターンを追加します。
(オプション) トリガーイベントで、Merge request ready to review、Merge request drafted、またはその両方を選択します。すべてのイベントに一致するように空のままにします。
(オプション) フィルターグループを再度追加を選択して、代替条件を表現します。
保存 を選択して設定を適用します。
プロジェクトごとに最大 5 つのフィルターグループを定義でき、グループごとに最大 20 のパターンを定義できます。各パターンは、最大 256 文字の有効な正規表現である必要があります。フィルターグループを追加しない場合、 はすべてのターゲットブランチに適用可能なすべてのイベントで をトリガーします。
トラブルシューティング
プライベート接続で GitLab Self-Managed を使用する場合の DNS、ネットワーク到達可能性、セキュリティグループ、または TLS エラーについては、「」を参照してくださいプライベート接続のトラブルシューティング。
一部のプロジェクトはプロジェクトリストに表示されません
症状
GitLab を正常に登録できますが、接続が予想される 1 つ以上のプロジェクトがプロジェクトリストに表示されません。
原因
Personal 接続の場合、 AWS DevOps Agent は、アクセストークンのユーザーがメンバーであるプロジェクトを一覧表示します。ユーザーが別の GitLab アクセスパスを介してプロジェクトを表示できる場合でも、そのユーザーがメンバーでない場合、プロジェクトは表示されません。
解決策
アクセストークンのユーザーが、接続する各プロジェクトのメンバーであることを確認します。
トークンの有効期限が切れておらず、「ステップ 2: GitLab 接続を設定する」に記載されているスコープが含まれていることを確認します。
プロジェクトメンバーシップを変更するか、トークンを置き換えたら、プロジェクトリストを更新します。
GitLab プロジェクトは接続できません
症状
プロジェクトへの接続が GitLab project '<path>' (ID: <id>) is not accessible to this GitLab token.または で失敗する GitLab is currently throttling requests (HTTP 429). Please retry the association later.
原因
トークンが選択したプロジェクトを読み取れないか、GitLab がプロジェクト検証リクエストを一時的にスロットリングしています。
解決策
トークンが有効であり、そのユーザーまたはグループが選択したプロジェクトにアクセスできることを確認します。
トークンに必要なスコープがステップ 2: GitLab 接続の設定に含まれていることを確認します。
GitLab が HTTP 429 を返す場合は、関連付けを待ってから再試行します。
GitLab 接続の管理
アクセストークンの更新 – アクセストークンの有効期限が切れるか、更新する必要がある場合は、登録を解除せずに更新できます。機能プロバイダーページで、GitLab 登録を選択し、アクションメニューから更新を選択し、新しいトークンを入力します。エージェントスペースの関連付けとプロジェクト接続は保持されます。
接続されたプロジェクトの表示 – AWS DevOps エージェントコンソールで、エージェントスペースを選択し、機能タブに移動して、パイプラインセクションで接続されたプロジェクトを表示します。
GitLab 接続の削除 – GitLab プロジェクトをエージェントスペースから切断するには、パイプラインセクションで接続を選択し、削除を選択します。GitLab 登録を完全に削除するには、まずすべてのエージェントスペースから削除してから、アカウントレベルで登録を削除します。