TECHSTEP

ITインフラ関連の記事を公開してます。

GitLab Comment templateを使ってみる

今回はGitLabのComment templateを触ってみました。

docs.gitlab.com

背景

GitLab Comment templateはIssue / Merge request / Epic等のコメント部分のテンプレートを提供する機能で、個人またはProject/Group単位でよく使うコメントなどを定義し、コメントを記載する手間を省くことができます。

なおGitLab Freeプランでは個人レベルでテンプレートを用意できますが、Premium / UltimateプランではProject / Groupレベルで共有できるテンプレートを利用できます。

検証

ここではFreeプランでComment templateを簡単に動かしてみます。

Comment templateは ユーザー設定 の左メニューにある コメントテンプレート から設定します。テンプレートを追加するため 新規を追加 を選択します。

テンプレートの作成画面は以下の通りです。ここではテンプレート名、テンプレートの内容を設定できます。

テスト用のテンプレートを設定後、例えばIssueの画面に移動します。このうち赤枠で囲った部分を押すと、設定したComment templateが表示されます。

設定したテンプレートの一覧が表示されるので、使いたいテンプレートを選択します。

テンプレートに設定した内容が表示されるので、このままコメントするか、更にコメントを追加することができます。

また以下のようにマークダウン形式でコメントしておくことで、EpicへのURLを追加するだけでコメントを完了させることもできそうです。

GitLab Protected branchを試す

今回はGitLabのProtected branchという機能を試しました。

docs.gitlab.com

背景

GitLabに限らず、ブランチに対する操作権限をコントロールすることは、リポジトリを安全に運用することにつながります。GitLabでは Protected branch という機能でブランチの保護を実現しており、この機能を使うと、例えばあるリポジトリへの変更はすべてMerge requestを経由しないとできない、といったコントロールが可能になります。どういったコントロールが可能かというと、大まかにいえば 誰が どのブランチに対して どんな操作を 許可するかを設定します。

検証

今回はGitLab Self-managed版 (Freeプラン) で protected-branch-test というProjectを作成し検証しています。また検証のため test というユーザーに Developer Roleを付与、 feature というブランチを事前に作成します。

Protected branchを設定するにはProjectの settings から Repository を選択し、Protected branches という項目があるので選択します。

Add protected branch を選択します。

遷移先の画面でProtected branchの設定を行います。設定項目は以下の通りです。設定後は Protect を選択します。

  • Branch : 対象のブランチを指定します。ワイルドカードを使って複数ブランチの指定も可能です。
  • Allowed to merge : mergeを許可するRoleを指定します。
  • Allowed to push and merge : push/mergeを許可するRoleを指定します。
  • Allowed to force push : 全てのユーザーにForce pushを許可するか選択します。

GitLabのドキュメントでは、以下の3つのパターンについて紹介しています。

  • 全員にMerge requestを要求する : Allowed to mergeDevelopers + Maintainers に、 Allowed to push and mergeNo one に設定します。
  • 全員に直接Pushを許可する : Allowed to push and mergeDevelopers + Maintainers に設定します。
  • 全員にForce pushを許可する : Allowed to force push を有効にします。

ここでは以下のようなProtected branchを設定します。

設定後は以下のように表示されます。なお設定を削除するには該当のブランチの Unprotect を選択します。

ここでは試しに test ユーザーで feature ブランチから main ブランチにMerge requestを作成します。この時は main ブランチに対するマージ権限は Maintainers にしか付与されていないので、 Developer Roleである test ユーザーにはマージはできないはずです。

Merge request作成後の画面を見ると Merge ボタンが見当たらず、 test ユーザーに割り当てられた Developer Roleではマージが許可されていないことを確認できます。

なおAdministratorユーザーに切り替えてMerge requestを見ると Merge ボタンを確認できます。

また、 test ユーザーで main ブランチ宛に新規ファイルを作成しようとしても、以下のようにエラーが表示されます。これは main ブランチに対する Allowed to push and merge の権限が Maintainer にしか付与されていないからです。

次にブランチ指定時にワイルドカードを使った場合を試します。事前に以下のように feature で始まるブランチを複数用意します。

Protected branch設定時は以下のようにワイルドカードを使用します。

すると以下のように 3 matching branches という記載が見えます。

これを選択すると以下の画面に遷移し、3つの feature* ブランチに適用されているのを確認できます。

さて、Protected branchを適用されたブランチに対し、以下のように削除をしようとします。

すると以下のように警告画面が表示され、削除するにはブランチ名を入力する必要があります。このようにProtected branchを有効にしたブランチは、誤って削除されることのないよう、削除時にチェック項目が追加されます。

なおprotectされていない場合は以下のような画面です

その他

Premium/Ultimateプランでは以下の機能も利用できます。

  • Protected branchに対し、最低1件のCode Ownerからの承認を要求できます。
  • Group/Userを Allowed to merge / Allowed to push and merge に追加できます。
  • Group内の全てのProjectに共通のProtected branchを追加できます。

Amazon CodeWhispererでCloudFormationコードを生成してみる

今回はAWS製のコード生成ツールであるAmazon CodeWhispererを使ってみました。

docs.aws.amazon.com

背景

Amazon CodeWhispererは機械学習を利用したコード生成を実行するサービスであり、コードを開発しながらリアルタイムにコードをサジェストしてくれます。コード生成サービスは複数ありますが、AWS公式ドキュメントに従えば、CodeWhispererは以下のような特徴を有しています。

  • AWSサービスで使用するために最適化されている: AWS API向けに最適化されたコードを提案し、AWSの各種サービスの効率的な使用を支援します。Amazonのコードをトレーニングに使っていることもあり、関連するクラウドサービスやライブラリを用いた提案、AWSのベストプラクティスを満たすコードの提案などを行います。
  • セキュリティスキャンとコード修復: CodeWhispererにはセキュリティスキャン機能を備えており、脆弱性の発見とそれを修正するコードを提案します。
  • エンタープライズ管理: CodeWhispererは、組織で利用するProfessional版を提供しており、AWS IAM Identity Centerを利用したSSOの提供、リファレンス付きコードの提案などを利用できます。

本記事投稿時点のCodeWhispererの対応する言語・IDEは以下の通りです。なお、言語によって訓練データが異なるため、(生成するコードの精度など?の) サポートの度合いは異なるようです。

検証

今回はVisual Studio CodeにCodeWhispererをインストールし、AWS CloudFormationを例に少しいじってみます。

Visual Studio CodeでCodeWhispererを利用するには、 AWS Toolkit for VSCodeをインストールします。

インストール後はサインインのオプションを選択する画面が表示されます。ここではCodeWhispererを利用するため Amazon Q + CodeWhispererUse for free, no AWS Account required を選択します。

CodeWhispererを無料で使うにはAWS Builder IDを使用します。事前に用意している場合はそれを利用しますが、まだの場合は作成から行います。

ログインしてVSCode画面に戻ると、以下のようにAmazon Qの画面が表示されます。これでCodeWhispererを利用する準備は整いました。

インストール後は以下のように操作します。

  • 手動でCodeWhispererを実行: Alt + c ボタン (Windows) / Option + c ボタン (Mac)
  • 提案をすべて了承する: Tab ボタン
  • 提案を1文字ずつ了承する: Ctrl + ボタン
  • 次の提案を表示する: ボタン
  • 前の提案を表示する: ボタン
  • 提案を否定する: ESC / back space ボタン

例えばUserdataを使用するEC2インスタンスの定義ファイルを生成するようコメントします。ここで改行 (または Alt+C ボタンを押下) すると CodeWhisperer is generating… と表示され、しばらくするとコードの候補が生成されます。コードに問題がなければ Tab または Ctrl + ボタンを押せばコードが書けます。

また、AWS Toolkit for VSCodeをインストールするとCodeWhispererと一緒にAmazon Qも利用できます。例えば表示しているコードの内容を説明するようチャット欄に記入すると、以下のように説明してくれます。

ただし、新しいリソースには対応していない場合もあります。例えば昨年登場したEKS Pod Identityに関するリソースを生成するよう指定しても、想定とは異なるコード (ここで生成されたリソースは実際には存在しません) が生成されました。

なお、CodeWhispererを使ったコードの開発は、AWSブログなどでも紹介されています。

さいごに

今回少しだけ触ってみましたが、コメントの内容に沿ってコードを生成するといっても、そもそも「あるリソースを」「どのような設定で」作成したいかが明確でないと、思ったようなコードを生成するのが難しいと感じました。なので、ある程度AWS CloudFormationを使い慣れており、用意したいリソースや設定も把握している人にとっては、作成するリソースの「大まかな雛形」を作成するには役立つのでは、と思います。ただし、あくまでCloudFormationを作成しただけの感想なので、もしかしたら汎用的なプログラミング言語はもっと違った結果なのかもしれません。例えばTypeScriptでAWS CDKを使ってリソースを定義するのはもっと楽になったりするのかもしれません。

一方で、ある程度書き進めていくと生成されるコードの精度が向上している感覚も得られました。分かりやすい例でいうと、 Parameters で複数の変数を設定後、それを !Ref で参照しようとすると、書きたいものが入力候補として最初に表示される、という体験は何度もありました。また、Resources.XXX.Type まで打った後に必要な Properties を設定するときは、設定しようと思ったパラメータ名が候補として登場する機会も多かったです。こういった体験もあり、「既にあるコードに手を加える」、あるいは「ある一定の量のコードを書き進めた後」の場合、CodeWhispererのいい部分が見えてきたと感じました。

なお、CodeWhispererに限らず生成AIサービスの精度は、時間が経つにつれてさらに改善されるものだと思うので、しばらくは使い続けたいと思います。

GitLabパイプラインエディタを紹介する

今回はGitLabのパイプラインエディタについて紹介します。

docs.gitlab.com

背景

パイプラインエディタはGitLabのUIから .gitlab-ci.yml を編集・テストできる機能です。具体的には以下のような機能を提供しています。

  • Edit : パイプラインエディタ画面では .gitlab-ci.yml を直接修正し、コミットすることが可能です。
  • Validate : .gitlab-ci.yml の編集中は、CI/CD パイプラインのベーシックな構文チェックが実行され、誤った箇所を指摘します。また Validate タブで検証を実施すると、 rules needs などのロジックに不適切な部分がないか、より詳細にチェックできます。
  • Visualize : Visualize タブでは、.gitlab-ci.ymlで定義したパイプラインが可視化されます。また include キーワードを使っている場合は、参照先のファイルも確認できます。

パイプラインエディタは gitlab-ci.yml に対する構文チェックをリアルタイムで行いつつ、パイプラインの修正を可能にします。GitLabに限らずCI/CDフローの定義ファイルを検証するには、修正後にコミットして実際に動かすことしかチェックできないこともあります。この機能は、実際にテストする前に構文チェックを行い、タイポなど単純なミスに素早く気付くことができます。

検証

今回は pipeline-editor-test というProjectで検証をしました。

ここでは以下のような .gitlab-ci.yml を使用します。

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script:
    - echo "This is build stage."

test:
  stage: test
  script: 
    - echo "This is test stage."
  
deploy:
  stage: deploy
  script: 
    - echo "This is deploy stage."

パイプラインエディタの表示

パイプラインエディタは ビルドパイプラインエディタ から表示します。

パイプラインエディタは以下の4つのタブを利用できます。

  • 編集 : ここでは画面上で .gitlab-ci.yml を編集できます。また編集中に構文的に問題があると、その旨を画面上に表示します。また変更内容をコミットしてパイプラインを起動したり、パイプライン画面にも移動できます。
  • 視覚化 : ここでは .gitlab-ci.yml の内容を可視化し、視覚的に理解できるようサポートします。例えば .gitlab-ci.ymlneeds が設定されていると、Job間の依存関係が線で表現されます。また include を含む場合、対象のファイルに移動もできます。
  • 検証 : ここでは .gitlab-ci.yml の挙動をシミュレーションし、想定通り動作するか確認できます。
  • 完全な設定 : ここでは 編集 での自動チェックよりもさらに詳細なチェック (ロジックを含む) を行うことができます。

まず 編集 では自動的に .gitlab-ci.yml の構文チェックを行い、問題があればUIに表示します。

視覚化 では、以下のように各Jobがどのstageで実行されるか表示されます。

検証 では以下のような画面が表示されます。検証時点では デフォルトブランチへのGitプッシュイベント しか選択できませんが、 パイプラインの検証 を選択します。

すると .gitlab-ci.yml に対してシミュレートを行い、問題なければ以下のように表示されます。

最後に 完全な設定 では、ロジックを含んだより詳細なチェックを行います。完全な設定では編集はできず閲覧のみ可能です。

新しいJobを追加する

まずは冒頭紹介した .gitlab-ci.yml をパイプラインエディタ上で修正する例です。ここでは test stageに別のJobを追加します。修正後は以下のように、 test Jobを削除して test01 test02 という2つのJobを追加します。

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script:
    - echo "This is build stage."

# 追加したJob
test01:
  stage: test
  script: 
    - echo "This is test01 job."
  
# 追加したJob
test02:
  stage: test
  script: 
    - echo "This is test02 job."

deploy:
  stage: deploy
  script: 
    - echo "This is deploy stage."

ここで修正中の画面の例を出すと、例えば以下の画像ではJobを定義するときに script: または trigger: というキーワードが欠けており、構文エラーであることを表示しています。

これを修正するとエラーは表示されず、代わりにCIの設定が有効であることを表示します。

修正が完了したので、これをリポジトリに反映します。ここでは main ブランチに向けてコミットします。

コミットするとパイプラインが実行され、パイプラインへのリンクも表示されます。

リンクを押してパイプライン画面に移動し、Jobの実行結果などを確認できます。

Job間に依存関係を与える

続いて needs: キーワードを使ってJob間の依存関係を設定する場合を見てみます。なお修正前の .gitlab-ci.yml を可視化すると以下のように表示されます。

ここで以下のように .gitlab-ci.yml を修正してみます。

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script:
    - echo "This is build stage."

test01:
  stage: test
  needs: ["build"] # needsを追加
  script: 
    - echo "This is test01 job."
  
test02:
  stage: test
  script: 
    - echo "This is test02 job."

deploy:
  stage: deploy
  needs: ["test02"] # needsを追加
  script: 
    - echo "This is deploy stage."

needs キーワードを含むと、視覚化 では以下のように、依存関係にあるJob間に線が引かれます。

なお、パイプライン画面でも ジョブの依存関係 を選択することで依存関係は表示されます。

include でテンプレートを呼び出す

最後に include キーワードを含む場合を見てみます。includeについては以前紹介しました。

techstep.hatenablog.com

パイプラインエディタは includeにも対応しており、includeで利用するファイルの表示、 includeで呼び出したJobを含む.gitlab-ci.ymlの表示などができます。

以下の画像では include-local-test というProjectをパイプラインエディタで見た場合を表示しています。このProjectでは2つのテンプレートを include:local で呼び出していますが、 include を含む場合はテンプレートファイルへの名前が表示され、これを選択すると対象のテンプレートの場所まで画面が遷移します。

また 完全な設定 タブに移動すると、include:local で指定したテンプレートの内容も含めた .gitlab-ci.yml の内容が表示されます。ここでは前の画面で表示されていた include: 以降の内容は消え、テンプレートで定義していた test-from-include deploy という2つのJobが追加されています。

GitLab Commit message templateを使ってみる

今回はGitLabのCommit message templateを紹介します。

docs.gitlab.com

背景

Commit message templateは、名称の通りコミット時に利用するテンプレートです。GitLabではMerge commit message / Squash commit messageの2種類のテンプレートが用意されています。

Commit message templateはいくつかの変数が提供されています。

  • %{source_branch}: コミット元の、マージされるブランチ名
  • %{target_branch}: コミット先のブランチ名
  • %{title}: Merge requestのタイトル
  • %{issues}: MRで言及、クローズしたIssue
  • %{reference}: Merge requestへのリファレンス

docs.gitlab.com

それぞれのデフォルトのテンプレートは以下の通りです。

Merge commit message template

Merge branch '%{source_branch}' into '%{target_branch}'

%{title}

%{issues}

See merge request %{reference}

Squash commit message template

%{title}

デフォルトのテンプレートの状態でMerge commitを作成すると、以下のように表示されます。

試しにMerge commit message templateを修正してみます。修正は 設定マージリクエスト 画面から可能です。

修正後にMerge commitを作成すると、以下のようにメッセージが変更されるのを確認できます。

GitLab rulesを試す

今回はGitLab rulesを少しだけ試してみました。

docs.gitlab.com

背景

GitLab CIに限らず、CI/CDのジョブを実行するタイミングを制御したいケースは多くあります。GitLabでは rules というキーワード配下に条件を指定することで、ジョブの実行タイミングを制御できます。

ここでは rules を使ったいくつかの例を簡単に検証しました。

検証

今回は以下のような .gitlab-ci.yml ファイルを使用します。

stages:
  - build
  - test
  - deploy

at-merge-request:
  stage: build
  script: 
    - echo "This job is executed at merge request."
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

at-file-change:
  stage: test
  script:
    - echo "This job is executed when target file is changed."
  rules:
    - if: $CI_COMMIT_BRANCH
      changes:
        - test.md

at-manual-execution:
  stage: deploy
  script:
    - echo "This job is executed at manual."
  rules:
    - when: manual

Merge request経由でだけ起動する

まずはMerge requestイベント発生時のみ起動するジョブを見ます。 .gitlab-ci.yml では以下のように rules:if を利用します。

job:
  script:
  rules:
    - if: $CI_PIPELINE_SOURCE == “merge_request_event”

$CI_PIPELINE_SOURCE はパイプラインがどうやって起動したか、そのイベントを格納する変数です。GitLabでMerge requestを作成・更新すると、この変数は merge_request_event となり、これと一致するときは特定のジョブを起動します。

ここではMerge requestを作成し、 at-merge-request というジョブだけが実行される様子を確認します。

適当なMerge requestを作成し、パイプラインを起動します。

パイプラインを確認すると、 at-merge-request というJobのみ実行されていることを確認できます。

試しにこのMerge requestをマージしますが、どのJobも実行されないことも確認できます。

特定のファイルが修正されたときのみ起動する

特定のファイルが変更されたときのみ起動するJobを用意したい場合、以下のように changes というキーワードを使うことで実現します。

job:
  script:
  rules:
    - changes:
        - <対象のファイル名を指定>

changes は、指定したファイルが変更するかをチェックし、変更時にのみJobを実行します。

ここでは test.md の変更があった時だけJobが起動する様子を確認します。なお今回の .gitlab-ci.yml で記載している $CI_COMMIT_BRANCH はコミットブランチ名が代入される変数で、ブランチからPushしたときにJobが起動するよう定義しています。

test.md を作成するとパイプラインが起動し、 at-file-change Jobだけが実行されます。

手動でのみ起動する

Jobを手動で実行する場合は when:manual を利用できます。

job:
  script:
  rules:
    - when: manual

when はJobをいつ実行するかを指定できます。ここでは when: manual と指定し、Jobを手動でしか起動できないよう指定しています。

when: manual と設定したJobは、以下のようにパイプライン画面から手動で実行できます。

Play と表示されるボタンをクリックするとJobは実行され、しばらく待つと完了します。

GitLab Wikiの紹介

今回はGitLab Wikiを紹介します。

docs.gitlab.com

背景

GitLab WIkiはGItLab Projectで利用できるWikiページを提供する機能です。GitLab WikiMarkdown / AsciiDoc / Rdoc / Orgをサポートしているほか、Wikiのページはサイドバーに表示され、サイドバーは利用者がカスタマイズ可能です。またGitLab WikiはGitLab Webページ上で編集できるほか、Gitを使ってローカルから編集もできます。

GitLabドキュメントでは、Wikiを使うケースとして ドキュメントをリポジトリに置きたくないがProjectに置きたい場合 を挙げています。具体的なケースとしては、以下のようなものがあるかと思います。

  • README.md には書ききれない、長文にわたるコンテンツ( Projectの利用方法や設計など) を記載する
  • 開発中のコードの変更履歴とは分けて管理したドキュメント (運用・開発ルールなど) を記載する
  • OSSの場合は、製品の目的や解決する課題などを紹介する。

また、GItLab 16.10で Wiki Template というテンプレート機能が導入されました。これにより、特定のテーマに沿ったWikiページをテンプレートから作成し、一貫したフォーマットでドキュメントを作成することができます。

検証

Wikiページの作成

ここからWikiを簡単に試してみます。GitLabの画面では 計画 からWikiのメニューに移動します。

Wikiのページを初めて作成するときは以下のような画面が表示され、 最初のページを作成 を選択します。

Wikiページの作成画面は以下の通りです。タイトルやフォーマット、内容を入力します。またWikiはGitリポジトリとして扱われるので、コミットメッセージを指定する必要があります。

Home画面を作成すると、以下のように表示されます。新しいページの作成は 新しいページ を選択します。

ここでは Home 配下に test というページを追加します。

右側のサイドバーを見ると、 Home/test という階層構造でページを作成したのを確認できます。

また各ページは、ページの履歴の確認、PDF形式でのエクスポートができます。

ページの履歴 を押すと、以下のように履歴が表示されます。

古い履歴を選択すれば、その時のページが表示されます。なお見た限りですが、古い履歴の内容をリストアすることはできなさそうでした。

Wiki templateの利用

docs.gitlab.com

Wiki templateは、Wikiページの右サイドバーにある テンプレート から操作できます。

新しいテンプレートを New template から作成します。

テンプレート作成画面は以下の通りです。通常のWikiページを作成するのとほぼ同じ内容です。

ここでは適当に template01 というテンプレートを作成します。

テンプレート作成後にWikiページの作成・編集画面に移動すると、用意したテンプレートを指定することができます。

作成済みのページ上でテンプレートを使って上書きするときは、以下のようにメッセージが表示されます。

その他

GitLab WikiにはGroup WIkiという機能があります。これはGitLab Groupで利用できる機能で、Group内のProjectが作成したWIkiをProjectをまたいで閲覧・エクスポートできるものです。

なおGroup WikiはPremium以上のプランで利用できます。