Note!
あくまで「やってみたらできた」的エントリーです。公式の方法ではありません。試すときは壊れてもいいリソースで。
act
なるものです。スゴイ。
同僚 (一度だけ実物見たことある) の YouTube 配信で「GitHub Actions のデバッグって大変ですよねー」と愚痴コメントしたら、その場で調べて教えてくれました。
GitHub actions のデバッグ、@okazuki さんに act というのを教えてもらったので試してみる。
— ほりひろ loves <⚡> (@hori__hiro) 2022年2月12日
Go 製のワン バイナリー ツールなので、(いつでも消せそうなので)気軽に入れられます。
各アクションの実行に Docker を使っているのでこれも必要です。
インストールは公式リポを参照ください。
act <event> <options>
みたいに実行すると、GitHub Actions の yaml ファイルを探して (既定では ./.github/workflows 以下)、<event> *1 にあった action を実行するみたいです。
Runner は Linux 限定、など制限はあるみたいですね。
Azure Static Web Apps
一方で Azure Static Web Apps (以下、SWA) 。 docs.microsoft.com
Azure Static Web Apps は、コード リポジトリから Azure にフル スタックの Web アプリを自動的にビルドしてデプロイするサービスです。
とあるとおり、GitHub Actions や Azure Pipeline を使ってGitHub (or Azure DevOps) のリポジトリにある静的サイトのコードをビルドして、Azure 上の SWA リソースにデプロイまでしてくれます。
SWA デプロイ用の GitHub Actions
この SWA デプロイ用の GitHub Actions を act でローカル実行し、Azure 上の SWA にデプロイできるか試してみました。
ぶっちゃけ、SWA デプロイ用の GitHub Actions は自動生成されるものなので、GitHub Actions 自体をデバッグすることはあまりないでしょう。それはうすうす気づいています。
あくまで、act を試してみた、という実験です。
以下、手順。
0. 事前準備
まず、SWA 自体を Azure にデプロイしておきます。GitHub と連携する必要はないです。
次にプロジェクトの用意 SWA にデプロイする予定のプロジェクトを GitHub 等に作成して、ローカルに git clone しておきます。
1. GitHub Actions の用意
./.github/workflows に下記 yaml ファイルに置きます。ほぼ自動生成されるものそのままです*2。
name: Azure Static Web Apps CI/CD on: push: jobs: build_and_deploy_job: if: github.event_name == 'push' || (github.event_name == 'pull_request' && github.event.action != 'closed') runs-on: ubuntu-latest name: Build and Deploy Job steps: - uses: actions/checkout@v2 with: submodules: true - name: Build And Deploy id: builddeploy uses: Azure/static-web-apps-deploy@v1 with: azure_static_web_apps_api_token: ${{ secrets.AZURE_STATIC_WEB_APPS_API_TOKEN }} repo_token: ${{ secrets.GITHUB_TOKEN }} # Used for Github integrations (i.e. PR comments) action: "upload" ###### Repository/Build Configurations - These values can be configured to match your app requirements. ###### # For more information regarding Static Web App workflow configurations, please visit: https://aka.ms/swaworkflowconfig app_location: "/" # App source code path api_location: "" # Api source code path - optional output_location: "dist" # Built app content directory - optional ###### End of Repository/Build Configurations ######
2. デプロイ トークンのコピー
Azure ポータルを開いてデプロイ トークンをコピーします。
yaml ファイルに書いた secrets.AZURE_STATIC_WEB_APPS_API_TOKEN として使います。
[概要] ブレードの 「デプロイ トークンの管理」からコピーできます。
3. .actrc の準備
act の実行設定として下記の内容を .actrc としてプロジェクトのルートに保存します。
-s AZURE_STATIC_WEB_APPS_API_TOKEN=<2. でコピーしてきたデプロイ トークン> -P ubuntu-latest=node:14.18.3-buster-slim -P ubuntu-20.04=node:14.18.3-buster-slim -P ubuntu-18.04=node:14.18.3-buster-slim
ここに書いてしておくと、act 実行時のオプションとして自動で読み込まれます。
最初の行は 2. でコピーした SWA のデプロイ トークンを貼り付けます。
-s FOO_BAR=... と書くと GitHub Actions 内で ${{ secrets.FOO_BAR }} で参照できます。
残りの行は runs-on: で指定するプラットフォームと使うコンテナー イメージの対応です。
ubuntu-*** と書いてあるのに Debian のイメージだったりしますが、細かいことはいいのかもしれません。気にしない。
ポイントは Node.js のバージョンをパッチ レベルまで指定していること。
Oryx (SWA のビルド エンジンである) は Node.js のサポート バージョンとしてパッチ レベルまで指定しています。
なので、マイナー/パッチを省略したバージョンを使うと、コンテナー レジストリ (Docker Hub) 内のイメージ更新で、いつか動かなくなるかもしれません。
ちなみに act を始めて実行する時、既定のプラットフォームのサイズを Micro とすると、ホーム ディレクトリ配下に .actrc を作りますが、node:12-buster-slim*3 が使われます。
一方で Node.js V12 の 2022 年 2 月現在の最新バージョンは v12.22.10 なので、上のスクショのように「バージョンが合わん」とエラーになります。
4. act を実行する
プロジェクト ルートはこうなっているはず。
$ tree -a . ├── .actrc ├── .github │ └── workflows │ └── azure-static-web-apps.yml ├── .gitignore ├── src │ : : └── staticwebapp.config.json
ここで act push を実行 (push イベントを発行) すると GitHub Actions が実行され、SWA 上にデプロイされるはずです。
まとめ
SWA の GitHub Actions を題材にしたのは反省しているが、act は使えそう。
