GitLab との連携

プロジェクトのロールにより、組織内でどのユーザーがどのプロジェクトにアクセスできるかを細かく制御できます。 これにより、チームには自分たちのプロジェクトのみへのアクセス権を付与し、一方で管理者には組織のより広いアクセス権を付与する、といった制御が可能になります。 アクセス権のオプションは以下の通りです。

すべての権限のリストは、「 ロールと権限」セクションをご確認ください。

現時点では、プロジェクトの設定ソースを追加または削除することができます。 上記の手順で GitLab と連携した場合は、GitLab の設定ソースが自動的に追加されています。

GitLab self-managed を使用している場合は、追加済みのインスタンスを設定ソースとして選択できます。 self-managed インスタンスの別の feature ブランチやリポジトリを新しい設定ソースとして使用する場合は、まず [Organization Settings (組織設定)] で新規連携を追加する必要があります。 どちらの場合でも、再びパーソナルアクセストークンを入力して連携を認証するように求められます。

設定ソースを定義すると、その設定ファイルを参照するトリガーをセットアップできます。

現時点では、パイプラインのスケジュール実行機能を GitLab で使用することはできません。GitLab のトリガーについては以下をお読みください。フィルタリング機能を使い、特定の条件に基づいてパイプラインをトリガーする方法も紹介しています。

パイプラインを開始する設定ソースを指定するトリガーを追加します。 上記の手順で GitLab と連携した場合は、GitLab が設定ソースとして設定されたトリガーが自動的に追加されています。

トリガーとトリガールールにより、CircleCI で変更ソース (この場合はGitLab) からのイベントをどのように処理するかが決まります。

トリガーが作成されると、CircleCI により Webhook が GitLab に登録されます。 GitLab からのプッシュイベントは CircleCI に送信されます。 CircleCI はその後、イベントデータを使って、パイプラインを実行すべきかどうかを決定し、実行する場合、どのパイプラインを実行すべきかを決定します。

各トリガーには、設定ソースに加えて、Webhook の URL のほか、このシナリオでは CircleCI で作成された GitLab トークンも含まれます。 GitLab レポジトリからプッシュイベントを受信するために、Webhook URL と GitLab トークンを使用して、GitLab に Webhook がセキュアに登録されます。

トリガーのフィルタリングにより、GitLab の Webhook に用意されているパラメーターに基づき、トリガーがビルドを開始するタイミングを決定できます。 CircleCI では、一般的なオプション (マージリクエスト時のみビルドを行うなど) を使用できるほか、フィルタリングのカスタマイズオプションを使って独自のルールを作成することも可能です。 たとえば、ビルドの開始条件を特定のブランチやユーザーに設定できます。

プロジェクトを作成すると、リポジトリからコードをチェックアウトするための SSH キーが作成されます。 作成した設定ファイルごとに、その設定ファイルに関連づけられたリポジトリのコードにアクセスするための SSH キーが新しく生成されます。 現時点では、[Additional SSH Keys (追加の SSH キー)] 設定は、GitLab プロジェクトにのみ適用されます。

ユーザーの追加と削除、および組織のユーザーロールとユーザー招待の管理を行えます。

GitLab self-managed の組織の場合、別の self-managed インスタンスを追加して組織に連携することができます。

GitLab.com を使用している場合は、 ユーザー設定でアカウント連携を管理できます。

CircleCI のユーザープロフィール内の [User Settings (ユーザー設定)] セクションで、複数のアカウント連携を有効化できます。

CircleCI で複数のアカウントと連携すると、以下のメリットがあります。

現在、プロジェクト設定、トリガー、および設定ファイル以外に GitLab との連携を管理する方法はありません。 CircleCI では、ユーザープロフィール内の [Account Integrations (アカウント連携)] でユーザーの GitLab アイデンティティを管理できるよう取り組んでいます。

冗長ワークフローの自動キャンセルは、現時点ではサポートされていません。 この機能の主な用途は、パイプラインのページからノイズを取り除き、コミットのフィードバックにかかる時間を短縮することです。 詳細は、 ジョブとワークフローのスキップとキャンセルを参照して下さい。

現在、GitLab 連携では、フォークしたプルリクエストにシークレットを渡すオプションはサポートされていません。

現在、GitLab 連携では、[Stop Building (ビルドの停止)] オプションをサポートしていません。他の連携では、このオプションは [Project settings (プロジェクト設定)] に表示されます。 CircleCI パイプラインの実行を停止したい場合は、GitLab リポジトリの Webhook を削除することを推奨します。

SSH での再実行は、アカウントを GitLab に加えて Bitbucket または GitHub と連携している場合にのみサポートされます。 ユーザーアカウントの Bitbucket または GitHub の SSH キーを使用して、GitLab について SSH での再実行を行えます。 CircleCI では、SSH での再実行を可能にするため、SSH の管理機能を追加予定です。 SSH での再実行では、コンテキストシークレットは渡されません。 CircleCI では、管理者がシークレットの使用と SSH での再実行をより詳細に制御できるよう取り組んでいます。

GitLab の連携では、デプロイキーとユーザーキーは使用されません。 GitLab のキーは、[Project Settings (プロジェクト設定)] > [Additional SSH Keys (追加の SSH キー)] に保存されます。 ただし、コードのチェックアウト用の SSH キーを手動で管理することは推奨されません。 代わりに、[Set Up Project (プロジェクトをセットアップ)] オプションまたは [Project Settings (プロジェクト設定)] > [Configuration (設定ファイル)] を使用し、リポジトリとの連携を維持して下さい。

現在、GitLab のお客様は、オープンソースプランをご利用いただけません。 CircleCI では、このプランの対象 VCS の拡大を進めており、最新情報についてはオープンソースコミュニティにお知らせします。

テスト インサイト機能は現在、GitLab のお客様には対応しておりません。