GitHub Actionsを自分で動かしてみて、理解を少しでも深めようの回
会社のプロジェクトでの開発時にGitHub Actionsを運用しているが、配属時には既に環境が整備されており、自分自身あまりちゃんと理解せず使っている。
というわけで、GitHub Actionsを自分で動かしてみて、理解を少しでも深めようの回。
GitHub Actionsの個人的なイメージ
GitHubのリポジトリにコードをpushした時に、GitHub Actions君が自動で仮想環境を作って、そこで事前に定義されたいろんな作業を実行してアウトプットを返してくれるサービス、という認識。
自動化する作業の例としては、コードの単体テストやフォーマットチェック、Dockerイメージのビルドなど。いわゆるCI/CDってやつ。
Circle CIとの違いはよくわかってないが、GitHub内でソースコード管理からCI/CDまでが完結するとなんとなく嬉しいことはわかる。
実際に動かしてみる
早速、GitHub Actionsを試してみる。動かすにあたりサンプルがほしいので、ここを参考にする。
手順
- GitHubリポジトリを作成
-
.github/workflows/配下にワークフローの設定ファイル(yml形式)を作成 - 設定ファイルをpush
手順自体は本当に簡単なもので、参考記事そのままの内容になりそうなので割愛。
一応、設定ファイルと実行結果だけペタリ。ちゃんと動きました。
設定ファイル
# ワークフロー名
name: Sample workflow
# トリガー
on: push
# ジョブ
jobs:
# 適当なジョブ名
sample_build:
# 実行環境
runs-on: ubuntu-latest
# アクション
steps:
- uses: actions/checkout@v2
- name: Run a one-line script
run: echo Hello, world!
実行結果
設定項目を簡単に調べてみる
動かしてみた設定ファイルの項目について、公式サイトのドキュメントで調べてみる。
name
ワークフローの名前を設定する。GitHub上には、リポジトリのアクションページなるものがあり、そこに表示されるとのこと。省略した場合、GitHubリポジトリのルートからの相対パスが名前として設定される。
on
ワークフローが自動で実行されるトリガー条件を設定する。条件は複数設定できる。
素人の所感としては、ここは基本的にpushが指定されることがほとんどなのかなという気持ち。実際は知らない。
他もあるが一旦保留。
特定のブランチにpushされた時、といった指定もできるみたい。
jobs
ここで、自動化したいアクションに関するを設定する。
ドキュメントによると、
訳： ワークフローの実行は、1つまたは複数のジョブで構成され、デフォルトでは並行して実行されます。
とのこと。逐次実行じゃなくて並行なのか。と思った矢先、
ジョブを逐次的に実行するには、jobs.<job_id>.needsキーワードを使用して他のジョブに対する依存関係を定義します。
よかった、逐次実行もできるみたい。
jobs.<job_id>
Use jobs.<job_id> to give your job a unique identifier. job_idキーは文字列型で、その値はジョブの設定データのマップとなるものです。 <job_id>は、jobsオブジェクトごとに一意の文字列に置き換える必要があります。 <job_id>は、英字または_で始める必要があり、英数字と-、_しか使用できません。
とのこと。リポジトリ内でユニークな文字列で設定してあげれば一旦何でも良さそう。命名に関する慣習とかあるのかな。
jobs.<job_id>.runs-on
アクションを実行するための仮想環境を設定する。
ドキュメントを見た限りだと、Linux系はUbuntuのみ選択可、他にWindows系やMacOS系も選べるみたい。
また、自分でサーバを立ててそれを指定することもできる？っぽいけど、ここではスコープ外なので先に進む。
jobs.<job_id>.steps.uses
ジョブでステップの一部として実行されるアクションを選択します。 アクションとは、再利用可能なコードの単位です。 ワークフロー、パブリックリポジトリ、または公開されているDockerコンテナイメージと同じリポジトリで定義されているアクションを使用できます。
アクションはどこかしらで事前に定義されているものを使用するみたい。
つまり、自分で何らかのアクションを実行したいと思った場合、事前にどこかしらで定義しておく必要があるということ？
ちなみに、実際に動かしてみた節の手順2の設定ファイルでは事前に定義されたアクション(actions/checkout@v2)が使用されている。このアクションは、ジョブを実行する際、pushされたリポジトリのcheckout(clone的な操作と想像している)を実行してくれる。これにより、リポジトリ内のファイルを使ってジョブが実行できるようになる。checkout先リポジトリは自分で指定できる。
このようなアクションは、GitHubが提供するマーケットプレイスで公開されている。つまり、ここで自分が書いたアクションを公開すればアクションとして指定できるようになるっぽい。
他にも自分で定義したアクションを実施する方法はあるっぽいが、ここでは調査を割愛。
Git ref、SHA、またはDockerタグ番号を指定して、使用しているアクションのバージョンを含めることを強く推奨します。 バージョンを指定しないと、アクションのオーナーがアップデートを公開したときに、ワークフローが中断したり、予期せぬ動作をしたりすることがあります。
アクションにもバージョンが定義されるっぽい。
ライブラリのバージョン指定と同じ感覚で運用できそう。
入力が必要なアクションもあり、入力をwithキーワードを使って設定する必要があります。 必要な入力を判断するには、アクションのREADMEファイルをお読みください。
アクションには入力が必要なものもあり、そういったものについてはjobs.<job_id>.steps.withで指定できるみたい。コマンド引数的な感じか。
jobs.<job_id>.steps.run
オペレーティングシステムのシェルを使用してコマンドラインプログラムを実行します。 nameを指定しない場合、ステップ名はデフォルトでrunコマンドで指定された文字列になります。
事前に定義されたアクションはuseキーワードで指定して実行できたのに対し、定義されていないアクションはrunキーワードでシェルで実行するコマンドを指定することで実行できるみたい。
やっぱり設定ファイルでも指定できた。
まとめ
というわけで、実際に動かして肌感も掴めたし、設定内容もなんとなく理解できた。
以上、GitHub Actionsを自分で動かしてみて、理解を少しでも深めようの回。
Discussion