はじめに
GitHub Actionsの作り方の紹介記事や実際に作成されたアクションが増えてきましたが、あまりいいとは思えない方法をちらほら見かけるので...
ビルドしたファイルや依存モジュールをデフォルトブランチで管理
変更したソース以外の変更が可読性の低い状態で多く混ざることがあり、PRでコードレビューをしても悪意のあるコードを見逃す可能性が高いため、リリース用のブランチ以外にビルドされたファイルや依存モジュールをコミットしてはいけません。
さもなければジョブごとに６０分間書き込み権限のあるGITHUB_TOKENを外部に送信するようなコードが紛れ込むかもしれません。
そもそもコントリビュートのしやすさや node のバージョンの違いによるバイナリの違い等を考慮すれば node_modules などはソース管理されるべきではないのは当たり前のことなので、これらが考慮されていない時点で大いに問題があります。
アクションの指定が master
READMEなどに書かれている使用例で master が指定されている場合、おそらく Compatibility を考慮していないのでしょう
on: push
name: test
jobs:
test:
name: Test
runs-on: ubuntu-latest
steps:
- uses: owner/repo@master
with:
abc: xyz
この書き方の場合、破壊的変更が入っても最新のものが実行されるため、いつの間にかワークフローが動かなくなるということが発生します。
前述のセキュリティの問題もこの指定の場合すぐに影響されます。
Conventional Commits などで適切にバージョンを決定し、タグを貼ってREADMEを書き直すべきです。
steps:
- uses: actions/javascript-action@master # do not do this
actions/toolkitのversioningに関するドキュメント
もちろん dist/index.js などのファイルも master から削除しなければなりません。
テストしにくい？
チェックアウトするのをリリース用のブランチやタグにすればいいだけです。
on: push
name: test
jobs:
test:
name: Test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
with:
ref: releases/v1
- uses: ./
with:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Semantic Versioning を使用していない
GitHubに安定した体験を提供するアクションを作成するときは、セマンティクスバージョニングを使用することをお勧めします
とあるように、将来的に継続した提供を考慮しているアクションでは Semantic Versioning の使用が推奨されています。
逆に Semantic Versioning が使用されていないアクションは問題があっても更新されない可能性や急に破壊的変更が入る可能性があると受け取られるため、メジャー、マイナー、パッチバージョンを考慮してタグを付与すべきです。
ただ、実際はリリースのたびにタグを貼り直す作業は非常に面倒であるため、パッチバージョン（e.g. v1.2.3）でタグが貼られていれば使用しても問題ないアクションだと考えています。
Docker タイプの GitHub Actions
Dockerfileを利用したアクションの場合、アクション実行前にビルドの動作が入るため遅いです。
どうしても必要なソフトウェアがインストールされていない、ソフトウェアのバージョンを固定したいなど理由があってのことであれば問題ないかもしれませんが、例えば「Linterを走らせるだけ」のような処理で使用するのは無駄に時間を浪費するだけです。
また if: failure() などでスキップされる場合もビルドは行われます。
したがって、失敗した場合にSlackに通知するみたいなことを行う場合に使用すると、失敗していないときの実行時間も増えてしまいます。
特にプライベートリポジトリの場合、無料枠を無駄に消費することになるのでJavaScriptで書き直したほうがいいです。