自動ビルドおよび自動テストにおける高度なオプション

読む時間の目安: 2 分

以降に示すオプションを利用することで、自動ビルドや自動テストの処理をカスタマイズすることができます。

ビルド時およびテスト時の環境変数

ビルド処理においては、いくつか便利な環境変数が設定されます。 これらは自動ビルド、自動テスト、フック処理時に利用することができます。

メモ: このような環境変数はビルド処理やテスト処理においてのみ利用されるものであって、サービス稼動環境に対して影響を与えることはありません。

  • SOURCE_BRANCH: テスト対象となっているブランチ名またはタグ名。
  • SOURCE_COMMIT: テスト対象となっているコミットの SHA1 ハッシュ値。
  • COMMIT_MSG: テストやビルド対象となっているコミットからのコミットメッセージ。
  • DOCKER_REPO: ビルドされている Docker リポジトリ名。
  • DOCKERFILE_PATH: 現在ビルドされている Dockerfile。
  • DOCKER_TAG: ビルドされている Docker リポジトリのタグ。
  • IMAGE_NAME: ビルドされている Docker リポジトリの名前とタグ。(この変数はDOCKER_REPO:DOCKER_TAGの組み合わせからなる。)

自動テストにあたってdocker-compose.test.ymlファイルにこれらの環境変数を利用する場合、以下に示すようにその宣言をsutサービス環境内で行います。

services:
  sut:
    build: .
    command: run_tests.sh
    environment:
      - SOURCE_BRANCH

ビルド、テスト、プッシュでの各コマンドのオーバーライド

Docker Hub では自動ビルドや自動テストの処理過程において、フックを利用することによってbuildtestpushの各コマンドをオーバーライドしてカスタマイズすることができます。 たとえばビルド処理においてのみ適用するビルド引数がある場合に、ビルドフックを利用できます。 (ビルド時のカスタムフック を設定することで、これらのコマンド間でのアクションを実行することもできます。)

フック利用時の注意 このようなフックファイルの内容は、基本となるdockerコマンドの内容を書き換えます。 したがってフック内には、同じようなビルド、テスト、プッシュの各コマンドを用意しなければなりません。 そうしないと自動処理が成功しません。

この処理工程に対するオーバーライドは、ソースコードリポジトリ内にhooksというフォルダーを生成することで実現します。 このフォルダーは Dockerfile と同じレベルのディレクトリ配下に生成します。 hooks/buildhooks/testhooks/pushというファイルを生成して、ビルド処理が実行可能なコマンド、たとえばdockerbashコマンド(適切に#!/bin/bashが宣言されたもの)などを記述します。

このフックは Amazon Linux 2 や Red Hat Enterprise Linux (RHEL) ベースの Linux において動作します。 こういった Linux であれば Perl や Python といったインタープリター、gitcurlのようなユーティリティーが含まれています。 利用可能なインタープリターやユーティリティーは、Amazon Linux 2 documentation から確認してください。

ビルド時のカスタムフック

フックを生成して利用することで、ビルド処理工程の合間にカスタムコマンドを実行することができます。 フックを利用して、自動ビルドや自動テストの処理に対して、追加の指示を行うことができます。

ソースコードリポジトリ内の Dockerfile と同レベルのディレクトリ内にhooksというフォルダーを生成します。 フックを定義するファイルはそのディレクトリに置きます。 フックファイルにはdockerコマンドかbashコマンドを含めることができます。 bashコマンドにおいては適切に#!/bin/bashを宣言しておく必要があります。 ビルド処理においては各処理工程の前後に、このファイル内のコマンドを実行します。

以下のフックが利用可能です。

  • hooks/post_checkout
  • hooks/pre_build
  • hooks/post_build
  • hooks/pre_test
  • hooks/post_test
  • hooks/pre_push (ビルドルールまたは 自動ビルド の実行時にのみ用いられます。)
  • hooks/post_push (ビルドルールまたは 自動ビルド の実行時にのみ用いられます。)

ビルドフックの例

ビルド処理時の変数のオーバーライド

Docker Hub ではビルド環境変数の定義をフックファイル内で行うことができます。 あるいは自動ビルドの設定画面にて行うこともできます(その後にフック内から参照します)。

以下に示す利用例ではビルドフックを定義し、そこではdocker buildの引数としてCUSTOMという変数を設定します。 その値は Docker Hub ビルド設定画面を通じて定義した変数値を用います。 また$DOCKERFILE_PATHという変数は、ビルド対象とする Dockerfile 名を定めるものです。 そして$IMAGE_NAMEはビルドするイメージ名です。

$ docker build --build-arg CUSTOM=$VAR -f $DOCKERFILE_PATH -t $IMAGE_NAME .

注意 hooks/buildファイルは、ビルド処理において用いられる基本的な docker build コマンドをオーバーライドします。 したがってフック内には同じようなビルドコマンドを用いなければなりません。 そうしないと自動ビルドは失敗します。

Docker のビルド時における変数についての詳細は docker build のドキュメント を参照してください。

複数リポジトリへのプッシュ

ビルド処理においてプッシュされるイメージは、デフォルトではビルド設定において定めているリポジトリに対してのみ行われます。 同じイメージを別の複数リポジトリにプッシュする必要がある場合は、post_pushフックを用いてタグを追加し複数リポジトリへプッシュすることができます。

$ docker tag $IMAGE_NAME $DOCKER_REPO:$SOURCE_COMMIT
$ docker push $DOCKER_REPO:$SOURCE_COMMIT

ソースリポジトリ / ブランチのクローン

Docker Hub がソースコードリポジトリからブランチをプルする際には、shallow クローン(指定ブランチの最新履歴のみのクローン)を行います。 これはリポジトリから取得する必要データ量を最小にする利点があり、必要最小限のコードがプルされていることからビルド時間の向上にも役立ちます。

ただしこのことがあるので、別のブランチに基づいたカスタムアクション(たとえばpost_pushフック)を行う必要がある場合には、そのブランチをチェックアウトするために以下のいずれかを行わなければなりません。

  • 以下のようにして対象とするブランチの shallow チェックアウトを行います。

      $ git fetch origin branch:mytargetbranch --depth 1
    
  • 「shallowではない」クローンを行うこともできます。 その場合には Git の全履歴を取得することになります(おそらく取得に時間を要し、多大なデータを取得することになります)。 取得するには--unshallowフラグを利用します。

      $ git fetch --unshallow origin
    
automated, build, images