CI on gkzz.dev

maestro testコマンドの `--test-output-dir` と `--debug-output` の違いをドキュメントとサンプルコードから追ってみる

Mon, 20 Jul 2026 00:00:00 +0900

はじめに

Maestro の maestro test コマンドでは、--test-output-dir と --debug-output などのオプションで、スクリーンショットやログなどの artifact が出力されます。両者はどちらも「artifact の保存先を指定するオプション」に見えるのですが、実際には扱うファイルがやや異なります。

この違いを意識しないと、落ちたテストの調査で「あるはずの artifact が見つからない」ということが起こりえます。たとえば、スクリーンショットを探していたら maestro.log しか入っていなかったり、逆にログだけ別ディレクトリに出ていたり。

そこで、この記事では maestro test の artifact 周りを整理します。また、ドキュメントとサンプルコードを頼りに、これらのオプションの違いや使用例を探ってみます。

この記事で最初に押さえたいのは、次の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 オプションの早見表をご覧ください。ここでは「flag の役割」と「実際に目に入る artifact」を分けて書きます。実際の挙動を見ると、ドキュメントのように、Yes / No の二値だけで読むと誤解しやすいので、まずは役割ベースで整理するほうがよいかと思います。

Firebase HostingとGithub Actionsで独自ドメインのHugoプロジェクトのブログを自動デプロイする

Fri, 20 Aug 2021 18:36:16 +0900

1.この記事で達成したいこと

独自ドメインのHugoプロジェクトのブログを作ってみたい
- そのブログがこれ！ –> https://gkzz.dev
ブログはHugo + Firebase Hostingで構成し、デプロイはGithub Actionsで自動化したい
- これまでローカルからデプロイという運用対処としていた、、

※Hugoのインストール手順はこちらに書いてあるのでどうぞ。

最新のHugoをインストールする方法とHugoの設定ファイルをtomlフォーマット以外にする方法 | gkzz.dev

2.前提

HugoのテーマはPaperMod
Firebase HostingとGoogle Domainsで購入したカスタムドメインを接続する方法は以下のとおり実施している
- Firebase HostingとGoogle Domainsで購入したカスタムドメインを接続する | gkzz.dev
- ドメインはgkzz.devとする

3.環境情報

$ grep Ubuntu /etc/os-release 
NAME="Ubuntu"
PRETTY_NAME="Ubuntu 20.04.2 LTS"
$ hugo version
hugo v0.87.0-B0C541E4 linux/amd64 BuildDate=2021-08-03T10:57:28Z VendorInfo=gohugoio
$

4.PaperModの導入

以下のPaperModのインストール手順を参考に進める
- https://github.com/adityatelange/hugo-PaperMod/wiki/Installation#method-2
- ※ https://github.com/adityatelange/hugo-PaperMod をサブモジュールとする点がミソ！
- 「6.GitHub Actionsの設定ファイル(.github/workflows/*.yml)を用意」で活きてくる！

$ hugo new site ${BLOG_DIR} -f yml
$ cd ${BLOG_DIR}
$ git init
$ git submodule add --depth=1 https://github.com/adityatelange/hugo-PaperMod.git themes/PaperMod

config.ymlのbaseURLにFirebase Hostingでホストしているカスタムドメインを指定

$ vi config.yml

# https://github.com/adityatelange/hugo-PaperMod/wiki/Installation
baseURL: https://gkzz.dev/
#languageCode: en-us
title: gkzz.dev
paginate: 5
theme: PaperMod

記事を書いてローカルサーバーにデプロイしてみる
- http://localhost:1313で接続できる

$ hugo new posts/<記事のファイル名>.md
$ hugo server -D

5.Firebaseのインストールと初期設定

以下のFirebase CLIのインストール手順を参考に進める
- Firebase CLI reference

$ curl -sL https://firebase.tools | bash
$ firebase login

略

Visit this URL on this device to log in:

********  <--- 表示されるURLからログイン認証を終える

Waiting for authentication...

✔  Success! Logged in as ********

Firebase CLIからGithubのログイン認証を終え、またfirebaseServiceAccountというサービスアカウントを作成
- 対話形式で進んでいく
- firebaseServiceAccountはGithub Actions上でFirebase CLIが使うもの

## 改めて設定し直したい場合
$ firebase init hosting:github

$ firebase init hosting

$ firebase init hosting
You're about to initialize a Firebase project in this directory:

  /path/to/${BLOG_DIR}


=== Project Setup

First, let's associate this project directory with a Firebase project.
You can create multiple project aliases by running firebase use --add, 
but for now we'll just set up a default project.

? Please select an option: Use an existing project
? Select a default Firebase project for this directory:
i  Using project ${GCP_PROJECT_ID}

=== Hosting Setup

Your public directory is the folder (relative to your project directory) that
will contain Hosting assets to be uploaded with firebase deploy. If you
have a build process for your assets, use your build's output directory.


## ${BLOG_DIR}からみた相対パス。PaperModの場合、public
? What do you want to use as your public directory? public


## シングルページではないのでNo
? Configure as a single-page app (rewrite all urls to /index.html)? No


## Yes
? Set up automatic builds and deploys with GitHub? Yes
✔  Wrote public/404.html
✔  Wrote public/index.html
i  Detected a .git folder at /path/to/${BLOG_DIR}
i  Authorizing with GitHub to upload your service account to a GitHub repository's secrets store.

Visit this URL on this device to log in:
********  <--- 表示されるURLからFirebase CLIからGithubのログイン認証を終える

Waiting for authentication...

✔  Success! Logged into GitHub as ${GITHUB_USERNAME}


##　${GITHUB_USERNAME}/${BLOG_DIR}
? For which GitHub repository would you like to set up a GitHub workflow? (format: user/repository) ${GITHUB_USERNAME}/${BLOG_DIR}

✔  Created service account ******** with Firebase Hosting admin permissions.
✔  Uploaded service account JSON to GitHub as secret ********
i  You can manage your secrets at https://github.com/${GITHUB_USERNAME}/${BLOG_DIR}/settings/secrets.

## 後ほど自分で書くのでNo
? Set up the workflow to run a build script before every deploy? No

✔  Created workflow file /path/to/${BLOG_DIR}/.github/workflows/firebase-hosting-pull-request.yml


## Yes
? Set up automatic deployment to your site's live channel when a PR is merged? Yes


## main (Firebase Hostingへデプロイするときのブランチ)
? What is the name of the GitHub branch associated with your site's live channel? main

✔  Created workflow file /path/to/${BLOG_DIR}/.github/workflows/firebase-hosting-merge.yml

i  Action required: Visit this URL to revoke authorization for the Firebase CLI GitHub OAuth App:
********
i  Action required: Push any new workflow file(s) to your repo

i  Writing configuration info to firebase.json...
i  Writing project information to .firebaserc...

✔  Firebase initialization complete!

ここまでくると、Github Actions上でFirebase CLIが使うfirebaseServiceAccountというサービスアカウントがご自身のブログのリポジトリの「settings > secrets」のページから登録されていることが確認できる。