deno-uddをGitHub Actionsで実行してDenoの依存モジュールのバージョン管理を自動化する
以下の記事でdeno-uddというツールを紹介しました。
Denoプロジェクトで使用している外部モジュールのバージョン確認と更新ができ、バージョンを固定したい場合や、上限を設けたい場合などの設定も可能な便利ツールです。
今回はその利用例として、これをGitHub Actionsで動かし、バージョン管理を自動化する方法を紹介します。
動作例
更新可能なモジュールがある場合、このようなプルリクエストが出されます。
設定ファイル
リポジトリに.github/workflowディレクトリを作成し、以下のudd.ymlを配置してください。
コメントは説明用のものなので削除をお願いします。
name: update-deno-dependencies
on:
schedule:
- cron: "0 0 * * *" # --[1]
jobs:
udd:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@master
- uses: denoland/setup-deno@v1
- name: Update dependencies
run: > # --[2]
deno run -A https://deno.land/x/udd/main.ts
$(find . -name "*.ts") --test="deno test -Ar"
- name: Create Pull Request # --[3]
uses: peter-evans/create-pull-request@v3
with:
commit-message: "chore(deps): update deno dependencies"
title: Update Deno Dependencies
body: >
Automated updates by [deno-udd](https://github.com/hayd/deno-udd)
and [create-pull-request](https://github.com/peter-evans/create-pull-request)
GitHub action
branch: update-deno-dependencies
author: GitHub <noreply@github.com>
delete-branch: true
多くのプロジェクトで、これをそのままコピペすれば動作すると思いますが、いくつか調整可能な点があります。
コード内にコメントした部分について解説します。
[1] スケジュールで定期実行する
cronを設定して定期実行しています。
上記の例では毎日00:00UTC（日本時間午前9時）に動作するようにしていますが、実行タイミングを変えたい場合はこちらを調整してください。
cronの構文の解説は既に様々な記事でされているため、そちらを参考にしてください。
なお、GitHub Actionsのスケジュール設定は確実にその時間に実行されることまでは保証されていません。
ノート: scheduleイベントは、GitHub Actionsのワークフローの実行による高負荷の間、遅延させられることがあります。 高負荷の時間帯には、毎時の開始時点が含まれます。 遅延の可能性を減らすために、Ⅰ時間の中の別の時間帯に実行されるようワークフローをスケジューリングしてください。
「00分」といった設定はとくに混雑しやすく、遅延が生じやすいようなのでご注意ください。
ただ、このワークフローは動作時刻が重視されるものではないので、個人的には気にしなくて良いと思っています。
[2] deno-uddを動かして依存モジュールを更新する
以下の記事で紹介した、「外部スクリプトを直接deno runする」方法でdeno-uddを動かしています。
以下の点で調整が必要な場合があります。
監視対象のファイルを変更する
バージョン監視対象として、find . -name "*.ts"の結果を引数として渡しています。
これは「プロジェクトルート以下の全ての.tsファイル」となります。
プロジェクトによってはモジュールを読み込んでいるファイルが複数に分かれていたり、サブディレクトリに入っている場合もあると考え、このように設定しています。
もしモジュールをdeps.tsで一元管理している場合、ここを単にdeps.tsに書き換えることができます。
パーミッションを制限する
deno run -Aで全てのパーミッションを許可した状態で実行していますが、厳密には、実行に必要なパーミッションは以下のとおりです。
-
read: 監視対象ファイルの読み込み -
write: 更新内容の書き込み -
net: モジュールの更新状況の確認 -
run: テストの実行（テストを行う場合のみ）
-Aではパーミッション制限が緩すぎると感じる場合はこれらを明示的に設定してください。
testオプションを調整する
deno testで実行される対象ファイルがない場合、このコマンドが失敗するため、モジュールの更新にも失敗します。
テストを作成していない場合は、--test="deno test -Ar"を丸ごと削除してください。
また、テストのパーミッションにも-Aを指定していますが、readだけで良いとか、そもそも不要といった場合もあると思いますので、状況に応じ適宜調整してください。
[3] プルリクエストを作成する
Create Pull Requestアクションを使用してプルリクエストを作成しています。
このアクションに渡す変数で、コミットメッセージやPRのタイトルなどを変更できます。
他にも設定できる項目があるので、説明ページを参考に調整してください。
また、git commit -am 'update dependencies' && git push originのようなコードに変更することで、PRを出さずに直接変更をpushしてしまうことも可能です。
このへんは以下の記事で紹介したものが参考になるかと思いますのでご覧ください。
プルリクエストではなく通知のみ欲しい場合
以下のように--dry-runした結果からAble to updateという文字列をgrepし、その返り値を!によって反転すると、「更新可能なモジュールがある場合に失敗するワークフロー」となります。
つまり、更新可能なモジュールがある場合に通知が飛びます。
name: check-deno-dependencies
on:
schedule:
- cron: "0 0 * * *"
jobs:
udd:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@master
- uses: denoland/setup-deno@v1
- name: Check dependencies
run: >
! deno run -A https://deno.land/x/udd/main.ts
$(find . -name "*.ts") --test="deno test -Ar"
--dry-run | grep -A 100 'Able to update'
grepに-A 100オプションをつけているのは、更新可能なモジュールの一覧を標準出力に出すためです（100件以上ある場合は表示しきれませんが…）。
おわりに
バージョン管理の自動化ツールとしてはDependabotがありますが、本記事執筆時点ではDenoには対応していません。
いずれDependabotやDeno公式からバージョン管理ツールが出るかもしれませんが、それまでは本記事で紹介したワークフローが役立つのではないかと思います。
バージョン管理から自分のリソースを解放し、よりクリエイティブな活動にフォーカスしていきましょう。
Discussion