GitHub Actionsに関する追記

GitHub Actionsをもう少し色々触ってみたのでそのメモ。

GitHub Actions
GitHub Actionsを学ぶ
とりあえずやるための設定
気づいたこと、気になったことなど

GitHub Actions

去年から使えるようになっていたGitHub Actionsですが、それまでTravis CIやWerckerというサービスを使っていて、それらをわざわざ移す必要もないかな、と思ってたのですが便利そうな部分も多いのでいくつか移行してみました。

ブログのビルド環境をGitHub Actionsに変更

その中で気づいたことなどについてメモしておきます。

GitHub Actionsを学ぶ

公式ドキュメントが充実しているのでまずはそれ参照。

GitHub Actionsのドキュメント - GitHub ヘルプ

GitHub Actions Documentation - GitHub Help

日本語版だと一部英語だったりして逆に読みにくいところもあるので英語読める人は英語版の方が読みやすいかと。

にはci のディレクトリに色々な用途別の例があります。

には公式以外も含めて色々と有用なものがまとめられています。

以下は最初に使える様になった時に試したときのもの。

GitHubで新しいActionsが使えるようになっていたのでCI/CDをやってみた

とりあえずやるための設定

GitHubのレポジトリに.github/workflowsというディレクトリを作って、その中に YAML形式の設定ファイルを置くことでGitHub Actionsが動きます。

まだ置いてないときは、レポジトリの上にあるActionsというタブを開くと Get started with GitHub Actionsというページに行って例の中から選んでスタートファイルとして使うことも出来ます。

とりあえず、まずやりたいこと、といえばレポジトリにpushした際にそのレポジトリの中身を色々チェックしたりすることだと思います。

それをするための簡単な設定は

.github/workflows/test.yml

name: Test

on:
  push:
    branches:
      - master

jobs:
  myjob:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2

    - name: Check my repository
      run: |
        echo checking...
        ls ./

ファイル名は何でもよくて、YAML形式のファイルをymlもしくはyamlという拡張子で .github/workflows/の中に保存すると見てくれる様になります。

nameは適当に。

masterブランチにpushされたとき、をトリガーにするなら上の様なonの設定に。

jobsの設定ではmyjobというジョブを定義してますが、この名前は何でもOK。

このジョブの中でまず環境を設定します。ここではUbuntuの最新版。

使えるものは以下を参照。

Ubuntu, macOS, Windowsがあります。

Ubuntuの最新版の環境とかはUbuntu1804-Readme.md を参照。 Homebrewとかも入ってます。

その後でstepsとして処理を書いていきます。予め用意されたアクションを使う場合にはuses、コマンドを書く場合にはrunで指定します。

これらのアクションはすべてGITHUB_WORKSPACEで定義されるディレクトリ (Ubuntuだと /home/runner/work/<repository name>/<repository name> ) で行われます。

事前のアクションでディレクトリを変更していても次のアクションはすべてここからスタートします。

runの方にはわかりやすいようにnameを指定してますが無くても良いですしusesの方でnameを指定してもOK。

runで複数処理をしたい場合には分けても良いですし、上の様にYAML的な複数行の書き方で書いてもOK。 (echo checking... && ls ./みたいなことも出来ます。)

このコマンドを打つ前にuses: actions/checkout@v2を呼んでますが、 GitHub Actionsでは用意される環境にはレポジトリがチェックアウトされてない状態なのでまずそれを取ってくる作業です。これでGITHUB_WORKSPACEがレポジトリのトップになります。

自分でTOKENなどを使って取ることも出来ますが、actions/checkout@v2 を使うのがデファクトスタンダードです。

気づいたこと、気になったことなど

細かい設定などは公式を参照すれば十分とは思うので省きますが特に気づいたことや気になったことなど。

メールでの通知を細かくは設定できない？

~~[通知の配信方法を選択する - GitHub ヘルプ]~~

追記: 2022/06/23

Configuring notifications - GitHub Docs

追記ここまで

上記では他のGitHubの通知と共にGitHub Actionsに関しても記述がありますが、設定はアカウント全体での設定で、

Email
Web
Send notifications for failed workflows only

という3つにチェックを入れるかどうか、だけです。

今はこれのEmailとSend notifications for failed workflows only にチェックを入れて失敗したときだけメールを送る、という設定にしています。

Travis CIとかだと各CIの設定ファイルの中で通知設定が出来て、失敗後、成功した場合にも通知(成功が続いた場合は通知しない)、など細かい設定も出来ます。

この辺はまたそのうちアップデートがあるんじゃないかな、と期待してます。

Pythonなどを使う場合にはsetupを呼ぶべし

Pythonのツールでpipを使ってインストールするものに関して、そのままpip install ...とやったところ、通常PATHの中に実行ファイルがインストールされるべきところされず使えない状態になってました。(どこにインストールされたか、もしくはモジュールがインストールされただけでPATHの中にはしてないのかはちゃんと確認してません。)

ubuntu-latestのデフォルトのPATHは

/usr/share/rust/.cargo/bin:/home/runner/.config/composer/vendor/bin:/home/runner/.dotnet/tools:/home/linuxbrew/.linuxbrew/bin:/home/linuxbrew/.linuxbrew/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

です。

PATHをちゃんと設定すれば、と思って試しましたがよくわからず。

そんな中、Pythonのセットアップアクションがあったのでそれを使ってみました。

- name: Setup python
  uses: actions/setup-python@v1
  with:
    python-version: 2.x
    architecture: x64
- name: python tool ...
  run: |
    pip install ...

こんな感じで actions/setup-python を呼ぶと、/usr/bin/pythonではなく、 /opt/hostedtoolcache/Python/2.7.17/x64/bin/python (pip) が使われるようになり、pipでインストールされるものも /opt/hostedtoolcache/Python/2.7.17/x64/binにインストールされる様になります。

また、このアクションを呼んだ時点でこのディレクトリがPATHに追加されます。

他にも Node.js, Java, goやRuby などのsetupもあるのでそういったものをrunで使いたい場合にはこれらを使ってセットアップした方が捗るかもしれません。

バッジ

Travis CIを使ってみた: GitHubのレポジトリにバッジを貼りたかったから

Travis CIとかで使えるビルドの結果などの状態の表示をするバッジ。

GitHub Actionsでも使えます。

ワークフローのステータスバッジをリポジトリに追加する

各レポジトリのActionsタブの各ワークフローのページからもバッジのスニペットを取得することも出来ます。

ただ、これらのものは状態表示の絵のURLがあるだけで、その状態を示すページへのリンクとかになってません。

![](https://github.com/actions/hello-world/workflows/Hello%20World/badge.svg)

クリックして結果ページに飛ぶようにするためには自分でURLを加える必要があります。

[![](https://github.com/actions/hello-world/workflows/Hello%20World/badge.svg)](https://github.com/actions/hello-world/actions?query=workflow%3A%22Hello+World%22)

トリガーの自由度は高い

GitHub謹製のツールなので、ということがあり、実行に使えるトリガーは豊富です。

pushだけでなく、IssueなどGitと直接関係ないものも含め、ありとあらゆるレポジトリの変化に対してワークフローが実行出来ます。

また、定期的な実行もschedule.cronで通常のcronジョブの様な書き方で指定できるのも良いところかと。

skip ci

レポジトリに対して何かアップデートをしてpushし直す、ということは良くあることですが、何も考えずにやるとそのpushに対して再びCIが走ってしまい、延々と繰り返されることになってしまいます。

これを避けるためにTravis CIとかだとコミットログに[skip ci]などが含まれていると CIを実行しない様になっています。

GitHub Actions does not respect [skip ci] - GitHub Community Forum

今の所GitHub Actionsではそのような機能はないのですが、同じようなことを

myjob:
  runs-on: ubuntu-latest
  if: "!contains(github.event.head_commit.message, '[skip ci]')"

  ...

と、jobs.<job_id>.ifで[skip ci]をコミットログに含まない場合、という指定をすることで再現することが出来ます。

多分この辺もそのうち改善されるのではないかな、と思うところ。

自作アクション

別に書こうと思います。

追記: 2020/04/23

GitHub Actions用のアクションを自作する

追記ここまで