本記事では以下の点で書いていきます。
- GitHub Actionsお試し実行
- Pull Requestとの連携（必須条件）
以下、目次となります。
Actionsの概要
公式サイトの概要ページを張っておきます。
一言で書くなら「任意トリガ（pushやissue作成等）を契機に、何かしらのアクション（ソースチェック、ビルド、通知、Issue作成や編集）などが出来る機能」でしょうか。
| 項目 | 内容 |
|---|---|
| 契機 | pushやpull_requestなど。 （on: [push, pull_request]） |
| 定義場所 | リポジトリ内 → .github/workflows配下にyml形式で。 |
| 実行場所 | GitHub.com内のコンピュータ（コンテナ）。 ※自前のオンプレ指定も可能です。 |
| コスト | publicリポジトリは無償。 privateリポジトリは有償だけど月2000分の無償枠有。 |
簡単なActionsなら1回1分未満です。
→ 実行環境によって消費倍率が異なります(Windowsは2倍、MacOSは10倍の消費）。
※月2000分は最低コア数2であれば約16USDです。
Push時に構文チェック
今回は次の前提条件で試してみます。
- Push時にpythonの構文チェックを行います。
→ 構文チェックは「compileall」を利用します。 - pythonファイルはリポジトリ内の「src/」フォルダに入っています。
次のようなActionsを定義して「.github/workflows」にpython.ymlとしてpushしておきました。
name: Python Syntax Check
on: [push]
jobs:
build:
name: Check Syntax
runs-on: ubuntu-latest
steps:
- name: Checkout Repository
uses: actions/checkout@v2
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: 3.7
- name: Check Syntax
run: python -m compileall src/例えば、次のようなコードを準備してsrcフォルダに格納します。
print('Hello World')特に問題が無い場合、Actionsの結果は次のようになります。
続いて、あえて構文エラーとなるように次のように変更します。
print('Hello World')
if※ifだけで終わっている内容ですね。
この場合、Actionsは次のような結果となります。
内容を確認すると「if」の部分で怒られていることがわかります。
Pull Requstの承認条件
続いて、Pull Requestの承認条件としてActionsが通っていることを条件とします。
Actionsは次のようにします（pull_request契機にしただけ）。
name: Python Syntax Check
on: [pull_request]
jobs:
build:
name: Check Syntax
runs-on: ubuntu-latest
steps:
- name: Checkout Repository
uses: actions/checkout@v2
- name: Set up Python
uses: actions/setup-python@v2
with:
python-version: 3.7
- name: Check Syntax
run: python -m compileall src/続いてリポジトリ設定の「Branch protection rule」に次のルールを設定しました。
- Check：Require status checks to pass before merging
- Check：Require branches to be up to date before merging
→ Add：Check Syntax
つまり、Python構文チェックのActions（Check Syntax）が通らないとマージは許可しない、という内容です。
この状態で作業用ブランチを切って、Pythonファイルを変更して、mainブランチへマージするためのPull Requestを発行します。
↓チェック中
↓チェック結果はNG（All checks have failed）。
ブランチ保護ルールの通り「Required statuses must pass before merging」となり、マージを実行出来ません（狙い通りガードが働いています）。
この後はどうすれば？
作業ブランチのファイルを修正しよう。
作業ブランチに修正したソースファイルをPushすれば、再度チェックをしてくれます。先ほど発行したPull Requestのチケットはそのままで再チェックしてくれるのは助かります。
All Checks have passedとなり、Pull Requestの内容をマージすることが出来るようになりました。
※今回はお試しのためActionsのチェックだけを条件をしていますが、レビューアによる承認を条件に追加することも可能です。
(参考) 色々なActions
要約
公式において、色々なActionsが準備されています。
- ビルドやパッケージ作成、リリース
- コードチェック
- 各種環境（AWSやAzuru等）にデプロイ
- Issueのラベル更新や作成。
などなど・・・。
予め準備されたActionsをうまく利用すれば、簡単にCI/CD等といったことを導入可能です。Jenkinsでも同じようなことが出来るとは思いますが、GitHub.com内に閉じて簡単に導入できるのが強みでしょうか。
ところで、コードチェックは「CodeQL Analysis」というものですが、コードの脆弱性をチェックしてくれるものです。Publicリポジトリであれば無償で利用出来ちゃいます。（その一方、Privateリポジトリであれば”advanced security”を購入する必要があって、Enterpriseライセンス費用よりもだいぶ高いです）。
Issueの自動クローズ
Actions/staleを利用します。
→ staleで検索して、そのままConfigureで初期設定するのが簡単です。
例えば、
- 一定期間動きが無い場合に催促メッセージを設定する。
- さらに動きが無ければ自動的にクローズする。
というのが、公式サイトに載っていたのでご紹介します。
次のコードは毎日1時30分（UTC）に動くワークフロー（Actions）です。
name: Close inactive issues
on:
schedule:
- cron: "30 1 * * *"
jobs:
close-issues:
runs-on: ubuntu-latest
permissions:
issues: write
pull-requests: write
steps:
- uses: actions/stale@v5
with:
days-before-issue-stale: 30
days-before-issue-close: 14
stale-issue-label: "stale"
stale-issue-message: "This issue is stale because it has been open for 30 days with no activity."
close-issue-message: "This issue was closed because it has been inactive for 14 days since being marked as stale."
days-before-pr-stale: -1
days-before-pr-close: -1
repo-token: ${{ secrets.GITHUB_TOKEN }}Issueに対して30日間更新がなければ催促し、さらに14日更新がなければクローズするといった内容です。Pull Requestチケットにも同様のことが可能です（-1を設定した場合は無効）。
※消費時間は「1分」に収まりました（課題10個程度の場合）。
まとめ
GitHubの便利機能である「Actions」についてご紹介しました。
- Actionsの概要
- お試しで、Push契機でPython構文チェック
- お試しで、Pull RequestでPython構文チェック＆マージ条件
最後までご覧いただきありがとうございました。
コメント