いわさです。
AWS CodePipeline ではいくつかの AWS 外部のソースプロバイダーがサポートされており、AWS CodeCommit や Amazon S3 以外にも GitHub や Bitbucket などのリポジトリをトリガーにしたパイプラインを構築することが出来ます。
本日のアップデートで、このサポートソースプロバイダーに GitLab が追加されました。
サポートされたのは SaaS 版の GitLab.com のリポジトリです。
ちょうど GitLab に Azure 連携用のリポジトリを持っていたので、こちらを使って試してみましたので設定の流れなどを紹介します。まぁ GitHub などとほぼ同じなのですが。
パイプラインのソースプロバイダーで指定するだけ
公式ドキュメントはこちらです。
GitHub などと同様に、外部リポジトリ側での認可が必要です。
パイプラインを作成すると Step2 でソースステージを追加します。
このソースプロバイダーで GitLab が選択出来るようになっています。
ソースプロバイダーに GitLab を選択後、GitLab.com アカウントへの接続を行う必要があります。
後述しますが、ここで構成しても良いですし事前に接続管理から接続を作成しておくことも出来ます。
ここではパイプライン作成時に GitLab 接続を行ってみましょう。
接続を開始すると、まずは接続名を作成する必要があります。
これは AWS 側で管理する接続名なので任意の名称で良いです。
ダイアログ上で GitLab への認証が要求されるので認証します。
認証後に接続リクエストに対する認可操作を行います。
接続ダイアログが AWS 側に戻ります。ここでもう一度「接続」ボタンを押す必要があるのでご注意ください。
私はここで「あれ？認可したのに接続できてない？」と少し混乱したのですが、よく見ると初回の画面とはちょっと違います。ここでもう一度操作が必要です。
GitLab リポジトリを CodePipeline のステージに接続する準備が完了しました。
リポジトリ名のテキストボックスで、GitLab 側で管理されているリポジトリが選択出来るようになっていると思います。
一点注意があって、本日時点ではグループプロジェクトのリポジトリがサポートされていません、ユーザーレベルのみのリポジトリがサポートされています。
あとのパイプラインの設定は CodeCommit や GitHub と同じですね。
今回は適当に CodeBuild プロジェクトでビルドさせてみました。
パイプライン作成後に次のように初回のパイプライン実行が完了しています。
GitLab リポジトリにプッシュしてみる
試しにパイプラインに連携した GitLab リポジトリに変更をプッシュしてみましょう。
適当なファイルを追加しました。
CodePipeline 側で実行されましたね。
新しいコミットが使用されています。
GitLab 側のパイプラインももちろん実行される
AWS 側でパイプラインが実行されるようになりましたが、もし GitLab 側でパイプラインを構成している場合はもちろんそちらも動作します。
GitLab の Webhook 設定でカスタマイズ出来そう
実際には GitLab 側では次のように Webhook が構成されています。
デフォルトの接続設定を行った後の Webhook トリガーは次のように設定されていますが、これは GitLab 側でコントロール出来そうですね。
AWS 側はデベロッパー用ツールの接続で管理
一方で AWS 側ではデベロッパー用ツールの接続として管理されています。
ここは認証・認可された接続情報が管理されているだけで、使い回すことが可能です。
また、接続自体はパイプライン構成画面ではなく、この画面からも作成が可能です。
AWS CodeBuild 単体のトリガーソースには指定できない
ビルドプロジェクトの実行方法ですが AWS CodePipeline 以外に、AWS CodeBuild 単体で使う場合が稀にあります。（私は検証用途でよくやる）
その場合、CodeBuild プロジェクト側でソーストリガーを指定するのですが、本日時点では CodeBuild 自体は GitLab に対応していませんのでご注意ください。CodePipeline と組み合わせて使う必要があります。
さいごに
本日は AWS CodePipeline のソースプロバイダーで GitLab リポジトリがサポートされたので使ってみました。
最近 Code シリーズが、外部 Git プロバイダーに統合したり、機能の一部を使えるようになったりと、何かそういった方向でのアップデートが多いですね。
GitLab 側のパイプラインが使えない事情があるとか、AWS 側のパイプラインを使いたい事情があるとか、特殊なユースケースに対応するためでしょうか。
3
