GitHub Actions

はじめに 私の dotfiles では、ローカルの dry-run と GitHub Actions で、設定の変更を確認できるようにしています。dotfiles の設定適用にはスクリプトを使っていたのですが、手を入れるうちにスクリプトとテストコードが増えてきました。 そこで、シンボリックリンクの作成・解除や、パッケージ・開発ツールの導入を mise bootstrap に寄せました。 この記事では、もともとスクリプトで行っていた処理と、mise に移したあとの設定やコマンドを紹介します。 1. もともとはスクリプトで導入・解除していた dotfiles のセットアップは、PC のリプレイスなどを除けば頻繁に実行するものではありません。 そこで、ローカルでは dry-run で適用・解除の内容を確認し、GitHub Actions では自動テスト用に HOME 相当のディレクトリを用意して、一連の操作を試せるようにしていました。 当初は、複雑なことをしていなかったので、mise のようなツールを使うのはオーバーキルだと考えていました。そのため、install / uninstall といった操作に使うスクリプトを書いていました。 その後、適用前に dry-run で内容を確認したい、ローカルと CI でできるだけ同じ操作を使いたい、と要件が増えていきました。導入処理とは別に、それらを支えるスクリプトやテストコードも増え、構成が複雑になってきました。 要件が増えるたびに、実装とテストの両方を変更する必要がありました。dotfiles の設定に加えて、導入・解除の仕組みも自分でメンテすることになっていました。そこで、mise bootstrap を使って、このあたりをまとめて管理することにしました。 2. dotfiles の配置とツールの導入を mise bootstrap にまとめる mise bootstrap は、[dotfiles]、[bootstrap.packages]、[tools] などの設定をまとめて扱います。dotfiles だけを操作したい場合は mise dotfiles のコマンドを使えます。 dotfiles だけを操作するには、mise dotfiles を使えます。 2-1. シンボリックリンクの配置先を [dotfiles] に書く mise.toml の [dotfiles] に、どのファイルをどこへ配置するかを記述します。下記は一例です。 [dotfiles] # "<target>" = { source = "<リポジトリをルートとした相対パス>", mode = "<symlink/シンボリックリンクなど指定したいモード>" } "~/.dotfiles" = { source = ".", mode = "symlink" } "~/.bashrc" = { source = ".bashrc", mode = "symlink" } "~/.bash_profile" = { source = ".bash_profile", mode = "symlink" } "~/.gitconfig" = { source = ".gitconfig", mode = "symlink" } "~/.config/mise/config.toml" = { source = "mise.toml", mode = "symlink" } 各エントリに mode = "symlink" を明示して、シンボリックリンクで配置するようにしています。たとえば、~/.bashrc にはリポジトリ内の .bashrc へのリンクを作ります。リンクの作成・解除は mise に任せるので、dotfiles 側では配置先の設定をメンテすることになります。 ...

1. はじめに このブログは Hugo で生成した静的ファイルを Cloudflare Pages から配信していました。今回、これを Cloudflare Workers の Static Assets から配信する構成へ移行しました。 前から気になっていたのが、Cloudflare Workers で Static Assets を配信できるようになったことです。長らく臭い物に蓋をしていたのはここだけの略 2024年9月、当社は静的アセットをホスト、保存、配信するためのベータサポートをCloudflare Workersで無料で利用できるようにしました。以前はCloudflare Pagesでのみ利用可能だったものです。 フロントエンド、バックエンド、データベースが1つのCloudflare Workerに ｜ Cloudflare ブログ 加えて、GitHub Actions で使っていた cloudflare/pages-action が deprecated になったことも、移行のきっかけでした。 Pages を使い続けることもできますが、この機会に Workers の Static Assets へ移し、GitHub Actions からのデプロイには cloudflare/wrangler-action を使うことにしました。 2. 移行にあたって Cloudflare には Pages から Workers への公式の移行ガイドがあります。 Migrate from Pages to Workers · Cloudflare Workers docs 今回はこの公式ガイドをベースに、コーディングエージェントにも助けてもらいながら移行を進めました。 実際にやってみると、Workers の設定だけではなく、GitHub Actions、Toolchain の管理、production deploy の扱い、Custom Domain の切り替え、旧 Pages プロジェクトの削除など、いくつか手を入れるところがありました。 ...

はじめに Maestro の maestro test コマンドでは、--test-output-dir と --debug-output などのオプションで、スクリーンショットやログなどの artifacts が出力されます。両者はどちらも「artifacts の保存先を指定するオプション」に見えるのですが、実際には扱うファイルがやや異なります。 この違いを意識しないと、落ちたテストの調査で「あるはずの artifact が見つからない」ということが起こりえます。 たとえば、スクリーンショットを探していたら maestro.log しか入っていなかったり、逆にログだけ別ディレクトリに出ていたり。 そこで、この記事では maestro test の artifacts 周りを整理します。また、ドキュメントとサンプルコードを頼りに、これらのオプションの違いや使用例を探ってみます。 この記事で最初に押さえたいのは、次の4点です。 --test-output-dir はスクリーンショットや動画の主な置き場 --debug-output は maestro.log の主な置き場 commands-*.json は artifact 調査で見ることになる主要なファイル --flatten-debug-output は --debug-output の artifact 群のディレクトリ階層をフラットにする レポート系のフォーマットは下記の2つです。 --format : レポートのフォーマット。 例：--format junit , --format html , --format html-detailed --output : 上記のレポートの出力場所。省略した場合はカレントディレクトリに出力。 例：--output build/report.xml なお、AI 系のレポートは生成条件が別なのでこの記事では深追いしません。 参考：https://docs.maestro.dev/maestro-flows/workspace-management/ai-test-analysis 1. --test-output-dir / --debug-output / --flatten-debug-output オプションの早見表 --test-output-dir / --debug-output / --flatten-debug-output オプションの早見表をご覧ください。 ...

1.この記事の立ち位置 自分がいつも調べていること、忘れがちな Tips や小ネタを列挙していく。そのため、網羅性は重視しない。 というのも、なにか調べていていろいろ読み漁った挙げ句、1周回って行き着くところは GitHub Actions の公式ドキュメントであり、たとえば Workflow の書き方は以下のページをよく開いている。 Workflow syntax for GitHub Actions - GitHub Docs それでも、公式ドキュメントで参照したい箇所を引っ張るための用語を知るまでに苦労することが往々にあり、この記事が、公式ドキュメントで参照したい箇所を導くための助けとなればと思い、書いていく。 2.Step と Job と Workflowの違いアレコレ 2-1.Step と Job と Workflow の違いの一行まとめ Step < Job < Workflow 2-2.Step と Job と Workflow の違いの三行まとめ Step はGitHub Actions Workflow の最小単位であり、run や uses で指定するもの Job はコンテナや VM のことを指し、runs-on で指定するものであり、ひとつないしは複数の Step を抱えている Workflow はひとつ以上の Job を束ねている これらについて端的にまとめた図が公式ドキュメントで掲載されているのでそちらもぜひ。 Understanding GitHub Actions - GitHub Docs 2-3.Step と Job と Workflow それぞれの分け方・分割の基準 Step を分けるときは、run 、 uses 、 name が異なるとき 以下のように書けば、ひとつの Step に複数のコマンドを始めとする処理を書くことができる - name: Install Dependencies run: | npm ci npm run build - name: Run test run: npm run test Job を分けるときは runs-on が異なるときや、needs で Job 単位で実行制御をしたいとき cf.4-1.Job をまたいで Step の実行を制御したり出力結果を参照したい Workflow を分けるときは、トリガーが違うとき e.g. push , pull_request , workflow_dispatch cf. Events that trigger workflows - GitHub Docs 3.Step の実行制御や Step の参照方法 以下のような成功するときもあれば失敗するときもある、不安定な Step があるとしよう。そして、このような不安定な Step の結果に応じて後続の Step を実行するかしないか決めたいとする。 ...

1.この記事を書こうと思った背景 Helmwave なるものを Twitter で見かけた。 Helmwave の README.md にはこのように書かれている。 Helmwave is helm3-native tool for deploy your Helm Charts. HelmWave is like docker-compose for helm. Helmwave は、Helm チャートを展開するための helm3 ネイティブツールです。 HelmWave は docker-compose のようなものです helm 用に作成します。 出所：helmwave/helmwave: 🌊 Helmwave is true release manager (邦訳は Google 翻訳より) よさそうなので、公式ドキュメントの Getting Started などを参考に Helmwave に入門する。 2.前提 2-1.ところで、Helm とは？ ぼくは、Helm 及び Helm Charts の理解も浅いのでこの場で深めておく。まず、Helm については公式ドキュメント にこのように書かれている。 The package manager for Kubernetes. Helm is the best way to find, share, and use software built for Kubernetes. ...