フロントエンドのビルド時に成果物を静的出力するようにしており、(静的出力された) 納品物としての証跡として運用をしている。
幸いこの成果物が必要になるほどこじれた事がないので転ばぬ先の杖と化しているけど、こういう運用は大事だよね。
という顔だったのだけど、先日掲題のエラーが出てビルドがぶっ壊れてしまい「なんだなんだ」と調査していた。
別のビルドは動いていた
フロントエンドのビルドに用いる GithubAction のワークフローは環境別に作成しており、integration/staging/production と環境ごとに分離している。
で、このうち staging/production が掲題のエラーで死んでいたのだけど、integration だけは問題なく動いていた。
何が違いなのかとワークフローの yml ファイルをチェックしていて以下に気づいた。
upload-artifact@v3
integration に対してはリモート環境で結合テストを行うかつエンドに提供していない環境、ということでビルド後は直接 aws s3 sync を利用してオリジンになる S3 バケットへ転送していた。
staging/production については静的出力のために、 actions/upload-artifact@v3 を利用しており、これが問題のようだった。
そもそも
Starting January 30th, 2025, GitHub Actions customers will no longer be able to use v3 of actions/upload-artifact or actions/download-artifact.
2025年1月30日から、GitHub Actionsの顧客は、V3のアクション/アップロードアーティファクトまたはアクション/ダウンロードアーティファクトを使用することができなくなります。
書いてあったのだけど気付いてなかったのだった……ヒーンすんません。
そして v4 へ
じゃあ雑に v4 にすればええんか？ と修正を作ったが、気になったので先人の知恵を調べてみることに。
安定のクラスメソッドくん、本当に助かるぜ……。
破壊的変更、に列挙されている内容はいずれも該当しなさそうなので雑に更新。
こうする
これだけ。
- name: Archive production artifacts - uses: actions/upload-artifact@v3 + uses: actions/upload-artifact@v4
あとはデフォルトブランチをこの修正が含まれているブランチに切り替えた上で、GithubActions から workflow_dispatvh: が有効なら手動、ないならなんかトリガー踏んで、このブランチを対象に実行する。
動いたら main なりに取り込む、という感じ。
おわりに
見回り用の bot とか入れてたとしても、人間が気づかないとどうしようもないんだな、とプロジェクトのみんなでしみじみしていました。
