GitHub ActionsのためのDockerfileサポート

注: GitHub ホステッドランナーは、現在 GitHub Enterprise Server でサポートされていません。 GitHub public roadmap で、今後の計画的なサポートの詳細を確認できます。

Dockerfileの命令について

Dockerfile には、Docker コンテナーの内容と起動時の動作を定義する命令と引数が含まれています。 Docker がサポートする手� �の詳細については、Docker ドキュメントの「Dockerfile リファレンス」を参照してく� さい。

Dockerfileの命令とオーバーライド

Dockerの命令の中にはGitHub Actionsと関わるものがあり、アクションのメタデータファイルはDockerの命令のいくつかをオーバーライドできます。予期しない動作を避けるために、DockerfileがGitHub Actionsとどのように関わるかについて馴染んでおいてく� さい。

User

DockerアクションはデフォルトのDockerユーザ（root）で実行されなければなりません。 Dockerfile では USER 命令を使用しないでく� さい。そうしないと、GITHUB_WORKSPACE にアクセスできなくなります。詳細については、Docker ドキュメントの "環境変数の使用" に関するページと USER リファレンスを参照してく� さい。

FROM

Dockerfile の最初の命令は、FROM とする必要があります。これにより、Docker ベースイメージが選択されます。詳細については、Docker ドキュメントの FROM リファレンスを参照してく� さい。

FROM 引数の設定には、いくつかのベストプラクティスがあります。

公式のDockerイメージを使うことをおすすめします。たとえば、python または ruby です。
バージョンタグが存在する� �合は使ってく� さい。メジャーバージョンも含めることが望ましいです。たとえば、node:latest の代わりに node:10 を使用します。
Debian オペレーティングシステ� に基づいて Docker イメージを使用することをお勧めします。

WORKDIR

GitHub Enterprise Server では、ワーキングディレクトリのパスを環境変数 GITHUB_WORKSPACE に設定します。 Dockerfile では、WORKDIR 命令を使用しないことをお勧めします。アクションが実行される前に、GitHub Enterprise Server では、GITHUB_WORKSPACE ディレクトリを、Docker イメージ内にあったその� �所になにがあってもその上にマウントし、GITHUB_WORKSPACE をワーキングディレクトリとして設定します。詳細については、"Docker ドキュメントの環境変数の使用" に関するページと WORKDIR リファレンスを参照してく� さい。

ENTRYPOINT

アクションのメタデータファイルで entrypoint を定義すると、それによって、Dockerfile 内に定義されている ENTRYPOINT がオーバーライドされます。詳細については、"GitHub Actions のメタデータ構文" に関するページを参照してく� さい。

Docker の ENTRYPOINT 命令には、shell 形式と exec 形式があります。 Docker ENTRYPOINT ドキュメントでは、ENTRYPOINT 命令の exec 形式を使用することを推奨しています。 exec 形式と shell 形式の詳細については、Docker ドキュメントの ENTRYPOINT リファレンスを参照してく� さい。

Dockerfile でエントリポイントを指定する� �合は、WORKDIR を使用しないでく� さい。代わりに、絶対パスを使用する必要があります。詳細については、「WORKDIR」を参照してく� さい。

ENTRYPOINT 命令の exec 形式を使用するようにコンテナーを構成した� �合、アクションのメタデータファイルで構成された args はコマンドシェルで実行されません。アクションの args に環境変数が含まれている� �合、その変数は置換されません。たとえば、次の exec 形式を使用すると、$GITHUB_SHA に� �納されている値は出力されませんが、代わりに "$GITHUB_SHA" が出力されます。

ENTRYPOINT ["echo $GITHUB_SHA"]

変数の置換が必要な� �合は、shell 形式を使用するか、直接シェルを実行してく� さい。たとえば、以下の exec 形式を使用すれば、シェルを実行して環境変数 GITHUB_SHA に保存された値を出力できます。

ENTRYPOINT ["sh", "-c", "echo $GITHUB_SHA"]

アクションのメタデータファイルで定義されている args を、ENTRYPOINT で exec 形式を使用している Docker コンテナーに指定するには、ENTRYPOINT 命令から呼び出す entrypoint.sh というシェルスクリプトを作成することをお勧めします。

Dockerfile の例

# Container image that runs your code
FROM debian:9.5-slim

# Copies your code file from your action repository to the filesystem path `/` of the container
COPY entrypoint.sh /entrypoint.sh

# Executes `entrypoint.sh` when the Docker container starts up
ENTRYPOINT ["/entrypoint.sh"]

entrypoint.sh ファイルの例

上の Dockerfile を使用すると、GitHub Enterprise Server によって、アクションのメタデータファイル内に引数として構成された argsが entrypoint.sh に送信されます。 entrypoint.sh ファイルの先� �に #!/bin/sh shebang を追� して、システ� の POSIX準� のシェルを明示的に使用します。

#!/bin/sh

# `$*` expands the `args` supplied in an `array` individually
# or splits `args` in a string separated by whitespace.
sh -c "echo $*"

コードは実行可能になっていなければなりません。ワークフローで使用する前に、entrypoint.sh ファイルに execute アクセス許可があることを確認します。この権限は、ターミナルから以下のコマンドで変更できます。

chmod +x entrypoint.sh

ENTRYPOINT シェルスクリプトが実行可能ではなかった� �合、以下のようなエラーが返されます。

Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"/entrypoint.sh\": permission denied": unknown

CMD

アクションのメタデータファイルで args を定義すると、args によって、Dockerfile で指定された CMD 命令がオーバーライドされます。詳細については、"GitHub Actions のメタデータ構文" に関するページを参照してく� さい。

Dockerfile で CMD を使用する� �合は、次のガイドラインに従ってく� さい。

アクションの README 中で必� �の引数をドキュメント化し、CMD 命令から除外します。
args を指定せずにアクションを利用できるよう、既定値を使用します。
アクションが --help フラグやそれに類するものを備えているなら、アクションを自己ドキュメント化するためにそれを利用します。

サポートされているLinuxの機能

GitHub Actionsは、DockerがサポートするデフォルトのLinuxの機能をサポートします。機能の追� や削除はできません。 Docker でサポートされる既定の Linux 機能の詳細については、Docker ドキュメントの「ランタイ� 特権と Linux 機能」を参照してく� さい。 Linux 機能の詳細については、Linux の man ページの "Linux 機能の概要" に関するページを参照してく� さい。

この記事では、次の� �目が扱われます。