本記事では以下の点で書いていきます。
- GitHub Actionsお試し実行
- Pull Requestとの連携(必須条件)
ActionsはJenkinsのように特定契機で指定した処理を、GitHub上のコンピュータで動かせる機能です。
例えば、リポジトリ内容をチェックアウトとしてソースコードの構文チェックをさせたり、ビルドを通したり、コードのテストを流したり・・・です。
以下、目次となります。
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って?
公式において、色々な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個程度の場合)。
マシンのスペック
例えば、「ubuntu-latest」の場合は次の通りです。
$ free -h
total used free shared buff/cache available
Mem: 7.7Gi 530Mi 6.2Gi 22Mi 1.1Gi 6.9Gi
Swap: 3.0Gi 0B 3.0Gi
$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 48 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Vendor ID: AuthenticAMD
Model name: AMD EPYC 7763 64-Core Processor
CPU family: 25
Model: 1
Thread(s) per core: 2
Core(s) per socket: 1
Socket(s): 1
Stepping: 1
BogoMIPS: 4890.85
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl tsc_reliable nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext invpcid_single vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves clzero xsaveerptr rdpru arat npt nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold v_vmsave_vmload umip vaes vpclmulqdq rdpid fsrm
Virtualization: AMD-V
Hypervisor vendor: Microsoft
Virtualization type: full
L1d cache: 32 KiB (1 instance)
L1i cache: 32 KiB (1 instance)
L2 cache: 512 KiB (1 instance)
L3 cache: 32 MiB (1 instance)
NUMA node(s): 1
NUMA node0 CPU(s): 0,1
Vulnerability Gather data sampling: Not affected
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Not affected
Vulnerability Retbleed: Not affected
Vulnerability Spec rstack overflow: Vulnerable: Safe RET, no microcode
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Retpolines, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
→ AMDの2コアに、約7GBのメモリでした。
控えめなスペックだけど、増強したい場合は・・・?
Larger Runnerというのがあるね。
まとめ
GitHubの便利機能である「Actions」についてご紹介しました。
- Actionsの概要
- お試しで、Push契機でPython構文チェック
- お試しで、Pull RequestでPython構文チェック&マージ条件
最後までご覧いただきありがとうございました。
コメント