## 経緯 それまで[[Claude Code]]にやってもらっていた[[GitHub]]でのリリースを[[Codex CLI]]でできるようにしてみる。 | 対象 | バージョン | | ------------- | ---------- | | [[macOS]] | 15.6.1 | | [[Codex CLI]] | 0.34.0 | ## コマンドの作成 0.26.0で[[カスタムプロンプト (Codex CLI)|カスタムプロンプト]]に対応したらしいので、[[マークダウンファイル]]を作ってみる。[[Claude Code]]で既に使っていたものを流用する。 `~/.codex/prompts/release.md` ````markdown # Release Command GitHubリポジトリのリリース作業を自動化します。 作業は英語ですが、私とのやりとりは日本語でお願いします。 ## 実行手順 1. **ローカルでpushされていないコミットがないことを確認** - pushされていないコミットがあれば中断 2. **CIが成功していることを確認** - `gh workflow` コマンドを使用する - GitHub ActionsのTestsワークフローが失敗していたら中断する - 成功していれば次へ 3. **リリース作業実行** - README.mdを参照してリリース手順を確認し実行 4. **リリース完了確認** - GitHubリリースページを定期的に確認 - 新しいリリースが作成されたことを確認 5. **関連issueに返信** - リリースに関係するissue(コミットメッセージに記載された#つきの番号)に対して - リリースした旨をコメントする - ステータスをclosedに変更 6. **Bluesky投稿準備** - リリース情報を取得してフォーマット - 投稿内容を出力 (ユーザーが手動でそれをコピー) - ユーザーが手動でBlueskyに投稿（OGPカード表示や動画添付が可能） 7. **リポジトリの最新化** - `git pull` でremoteの変更点を取り込む ### 4について #### コメントフォーマット ``` <投稿者全員にメンション> Released in [<バージョン>](<リリースノートのURL>) 🚀 ``` **具体例:** https://github.com/tadashi-aikawa/obsidian-another-quick-switcher/releases/tag/13.7.1 の場合 ``` @craziedde Released in [v13.7.1](https://github.com/tadashi-aikawa/obsidian-another-quick-switcher/releases/tag/13.7.1) 🚀 ``` ### 5について #### 投稿フォーマット ``` 📦 ${プロダクト名} ${バージョン} 🚀 ・箇条書きで新機能やメインの変更点を列挙 ${GitHubリリースページのURL} ``` ## 必要な設定 - GitHub CLIが認証済みであること ## 使用方法 ``` /release ``` このコマンドを実行すると、上記の手順が自動的に実行されます。 ```` ## リリースしてみる `/release` を実行する。中身が表示される点が[[Claude Code]]と異なる。 > [!left-bubble] ![[chappy.webp]] > これからリポジトリを確認して、READMEのリリース手順とスクリプト配置先を把握します。続けて自動化用スクリプトを追加します。 スクリプト追加されると困るので、interruptして指示を追加。 > [!right-bubble] ![[minerva-face-right.webp]] > 自動化用スクリプトを追加とありますが、スクリプトは追加しないでほしいです。コマンドで作業お願いします。 少し様子見する。 > [!left-bubble] ![[chappy.webp]] > • Updated Plan > └ 手順をコマンドで順に実行します。適宜結果を確認しつつ進めます。 > □ 未pushコミットの有無を確認 > □ CI(Tests)の最新結果を確認 > □ Release Actionを手動トリガー > □ リリース作成完了の確認 > □ 関連Issueへコメントとクローズ > □ Bluesky投稿文の整形出力 > □ git pullで最新化 実際には、内部でどのようなスクリプトを使っているか、常に許可を求めてくる。これは『どうせ内部はスクリプトなんだから、自動化スクリプト作らせてよ』という主張に聞こえる。しばらく使ってみて、作ってもらうように頼む未来が見えるけど今は静観。 issueへのコメントを全自動でやってくれようとしていたけど、誤爆が怖いので確認を挟んでもらうように。 > [!right-bubble] ![[minerva-face-right.webp]] > コメントしようとしているissueが妥当かどうかを一覧、または個別に確認するフェーズを挟んでください。コメント先が問題ない場合、そこからクローズするのは自動で問題ありません。 > [!left-bubble] ![[chappy.webp]] > • Updated Plan > └ ユーザー要望に合わせ、コメント対象Issueの妥当性確認フェーズを追加しました。先の4手順は完了済みに更新します。 > ✔ 未pushコミットの有無を確認 > ✔ CI(Tests)の最新結果を確認 > ✔ Release Actionを手動トリガー > ✔ リリース作成完了の確認 > □ 関連Issue候補の抽出と確認 > □ 関連Issueへコメントとクローズ > □ Bluesky投稿文の整形出力 > □ git pullで最新化 しかし、全部[[Shell]]でやろうとしているのが本当にエグい。[[Shell]]は人類には早すぎる言語だと思っているけど、相手は人類じゃないからな。。 いちいちスクリプトまで見る気にならないので、脳死でacceptしてる。 途中で全然報告してくれないのに、操作の許可だけ求めまくってくるので不安になっていたが、最後にちゃんと日本語で報告してくれた。 > [!left-bubble] ![[chappy.webp]] > 次は関連Issue候補を洗い出して確認します。見つかればコメント→クローズに進みます。 > > 進捗サマリ > > - 未pushコミット: なし > - Testsワークフロー: success を確認 > - Release Action: 手動トリガー→完了 > - リリース作成: 13.20.0 を確認 > > リリース情報 > > - バージョン: 13.20.0 > - リリースURL: https://github.com/tadashi-aikawa/obsidian-another-quick-switcher/releases/tag/13.20.0 > > 関連Issue確認フェーズ > > - 対象コミット範囲: 13.19.0..13.20.0 > - コミットメッセージ中の「#番号」参照: 0件 > - 結果: コメント・クローズ対象のIssue候補はありませんでした > - ご要望どおり「妥当性確認フェーズ」を挟みましたが、該当がないためこのステップはスキップします > > Bluesky投稿文（コピー用） > > - 以下をそのまま投稿してください（必要に応じて調整可） > > 📦 Another Quick Switcher 13.20.0 🚀 > > ・main/backlink/grep: check/uncheck items > > https://github.com/tadashi-aikawa/obsidian-another-quick-switcher/releases/tag/13.20.0 > > 最新化 > > - git pull 実行済み（Fast-forward） > - 更新: manifest.json, manifest-beta.json, package.json, versions.json > > この後、Issueに手動で紐付けたいものがあれば番号をご指定ください。必要なら再確認リストを作成し、指定分のみコメント・クローズまで自動で行います。 おお... 完璧ではないか。マイクロマネジメント的な思想ですまないと思っている。。 まあでも関連issue見分けるの以外はほとんどスクリプト書けば自動化できるよなぁ。。 ## リリーススクリプトを作成してもらう [[🦉Silhouette]]のリポジトリでお願いしたときに、[[Bun]]のリリーススクリプトを書いてくれたので試してみることに。気になったので質問したところ、自分の考えをしっかり持っていて良い。 ~~[[Claude Code]]だと『その通りです！ 修正します！』だから~~ > [!right-bubble] ![[minerva-face-right.webp]] > これは修正依頼ではなく質問です。 > > Bunだと$とテンプレートリテラルでBun Shellが使えると思いますが、そちらを使わなかった理由は？ > > ```ts > import { $ } from "bun"; > > const stdout = await pwd`.text(); > console.log(stdout); > ``` > [!left-bubble] ![[chappy.webp]] > 私は今回、以下の理由で Bun.spawnSync を使いました： > > - 引数のエスケープを自前で制御したかったからです。 `...`` はシェル展開を通るので、Issue番号など動的に組み立てる文字列にスペースや記号が含まれる場合の逃がし方を毎回気にする必要がありま > す。`spawnSync` に配列で渡せば OS コマンド実行レベルで安全に引数化できます。 > - 失敗しても処理を続けたいコマンド（allowFailure 相当）を細かく扱いたかったためです。 $ でも .nothrow() で同様のことはできますが、結果オブジェクトの扱いがバラつくので、共通ヘルパー関数と > してまとめた方がスクリプト全体のエラーハンドリングを統一しやすいと判断しました。 > - 標準出力・標準エラーの両方を常に文字列で取り出したかった（後続の解析に使うため）。spawnSync なら stdout/stderr をそのまま取り出せるのでログ整形を自前でしやすいメリットがあります。 > > もちろん `...`` を使っても同じことはできますが、今回のように「逐次的に CLI を叩きつつ、失敗許容やログ整形を統一したい」ケースでは、spawnSync ベースの薄いラッパーを用意した方が書き下しやすいと考えました。 > [!right-bubble] ![[minerva-face-right.webp]] > execFile使ったほうがよくないですかね？ > [!left-bubble] ![[chappy.webp]] > execFile も候補ですが、今回あえて Bun.spawnSync を選んだのは次の理由です。 > > - Bun で完結したかった：execFile は Node.js の child_process API なので、Bun ランタイム下では互換機能に頼る形になります。将来的な差異や非対応挙動を避け、Bun が公式に推している spawn/ > spawnSync 系を使う方が安定だと判断しました。 > - 標準出力／標準エラーの扱いがシンプル：spawnSync なら結果オブジェクトからバイナリをそのまま受け取れるので、共通ヘルパー内で文字列化してロギングやパースを統一しやすいです。execFile だと > コールバックや Promise ラッパーを用意するひと手間が増えます。 > - 逐次的に待機する処理と相性が良い：リリースフロー全体が「コマンド実行 → 結果チェック」の繰り返しなので、同期版でそのまま書いた方が読みやすく、例外も try/catch に流し込みやすくなります。 > execFileSync を使う方法もありますが、結局 Node API に依存します。 > > もちろん Node.js ベースで実装するなら execFile は良い選択ですが、Bun 固有の環境・依存関係を優先して今回の形にしています。 > [!right-bubble] ![[minerva-face-right.webp]] > なるほど。ちなみに `gh api repos/tadashi-aikawa/silhouette/actions/workflows/tests.yaml/runs` だと成功するのはなぜ？ > [!left-bubble] ![[chappy.webp]] > `gh api repos/tadashi-aikawa/silhouette/actions/workflows/tests.yaml/runs` は単なる「閲覧系 API（GET）」なので、従来どおり `repo` 相当のスコープさえあれば 200 で返ってきます。 > > 一方、スクリプトが失敗していたポイントは repos/.../actions/workflows/release.yaml/dispatches への POST（ワークフローの手動トリガー）で、ここは GitHub 側が「workflow スコープを持っていな > いトークン」に対して 404 を返す仕様です。つまり、 > > - `.../runs` → 読み取りだけなので従来のトークンで成功 > - `.../dispatches` → 手動実行なので `workflow` スコープ必須。足りないと 404 > > という差です。`gh auth refresh -s repo -s workflow` 等で workflow を付け直した後は、両方とも正常に動作するようになります。 > [!right-bubble] ![[minerva-face-right.webp]] > 以前にClaude CodeやCodex CLIに頼んだときは、こちらでgh auth refreshコマンドを利用せずとも、Actionを実行してリリースしてもらえました。 > > これはAIが `gh auth refresh` コマンドを気を利かせて実行してくれていたということですか？ > [!left-bubble] ![[chappy.webp]] > 可能性としてはいくつか考えられますが、「AI が勝手に `gh auth refresh` を実行してくれた」ケースはむしろ例外的です。Codex CLI / Claude Code などが実行していた過去のリリースでトークンの更新を 省略できていた理由としては、以下のほうが現実的です。 > > - その時点では `workflow` スコープ付きのトークンがすでに保存されていた > CLI の認証情報は ~/.config/gh（mise 経由だと管理場所が異なることもありますが）に保存されるので、以前に人手でログインした際に `workflow` を付けていたなら、追加の `auth refresh` 不要で `dispatch` が通ります。 > - AI が `gh auth login` や `gh auth refresh` を実行していた可能性 > Codex CLI や Claude Code は、必要に応じて「認証を更新するコマンド」を自律的に叩くことがあります。ユーザーに明示されていなかったとしても、ログを見ると `gh auth login／refresh` を走らせて > いたケースはありえます。 > - たまたま GitHub 側が `workflow` なしでも許可していた期間 > これはほぼ無いと思いますが、GitHub の仕様変更やトークン作成環境によって、repo スコープに暗黙で `workflow` が付いていた時期が一時的にあった可能性はゼロではありません。 > > 今回 404 になったということは、現在手元の gh が保持しているトークンから `workflow` スコープが抜けている（か、GitHub 上でスコープが取り消されている）と見てよいです。ですので、改めて `gh auth refresh -s repo -s workflow` でスコープを付け直しておくのが確実です。 > [!negative] あとで分かったけど > 結局原因は **メソッドがPOSTになっていたこと** だったぽいのでscopeは関係ないかも。。 たしかにスコープはなさそう。 ```console $ gh auth status github.com ✓ Logged in to github.com account tadashi-aikawa (GITHUB_TOKEN) - Active account: true - Git operations protocol: ssh - Token: ghp_************************************ - Token scopes: 'public_repo', 'repo:status' ! Missing required token scopes: 'repo', 'read:org' - To request missing scopes, run: gh auth refresh -h github.com ✓ Logged in to github.com account tadashi-aikawa (keyring) - Active account: false - Git operations protocol: ssh - Token: gho_************************************ - Token scopes: 'gist', 'read:org', 'repo' ``` ちょっと怖いので聞いてみる。 > [!right-bubble] ![[minerva-face-right.webp]] > repoだけでなくworkspaceのトークンが必要な理由を教えて下さい。 ※ 間違えて `workflow` ではなく `workspace` にしてしまった... けど通じた > [!left-bubble] ![[chappy.webp]] > `repo` スコープは「リポジトリ内のコード・Issue・PR などを読み書きする」ための権限で、今回のスクリプトでも以下の操作に必須です。 > > - `gh issue comment` / `gh issue close` で Issue にコメント・クローズする > - `gh release list/view` でリリース情報を取得する > > 一方、Release Action を手動で走らせる処理は `gh api repos/.../actions/workflows/release.yaml/dispatches` を叩いており、これは GitHub Actions をユーザー操作で起動する権限（workflow スコープ） が必要です。GitHub は安全性のためにこのエンドポイントを `workflow` 権限で守っているため、repo だけだと 404（実質的な権限不足）になります。 > > つまり： > > - Issue やリリースに対する読み書き → `repo` が必要 > - Release Action を dispatch する → `workflow` が必要 > > この両方を行う今回のフローでは、`repo` と `workflow` の双方を付与したトークン（= `gh auth refresh -s repo -s workflow` などで更新した認証情報）が必要、というのが理由です。 シゴデキ感漂う回答だ。。[[Claude Code]]も絶頂期はこんな感じだった気がするんだけどなぁ...残念。 > [!right-bubble] ![[minerva-face-right.webp]] > ``` > $ gh auth refresh -s repo -s workflow > The value of the GITHUB_TOKEN environment variable is being used for authentication. > To refresh credentials stored in GitHub CLI, first clear the value from the environment. > ``` > [!left-bubble] ![[chappy.webp]] > `gh` は環境変数 `GITHUB_TOKEN` が設定されていると、そちらを優先的に利用します。 その状態だとローカルに保存しているトークン情報を更新できないため、以下のいずれかの方法で一時的に環境変数を外してから `gh auth refresh` を実行してください。 > > 1. 一度だけ更新したい場合 > > unset GITHUB_TOKEN > gh auth refresh -h github.com -s repo -s workflow > （Zsh/Bash はシェルを閉じるまで `GITHUB_TOKEN` が外れた状態になります） > （Zsh/Bash はシェルを閉じるまで `GITHUB_TOKEN` が外れた状態になります） > 2. 端末を開くたびに `GITHUB_TOKEN` が自動でセットされてしまう場合 > .`zshrc` やシェル起動時に読み込まれる設定ファイルで `export GITHUB_TOKEN=...` が書かれていないか確認し、常時不要であればコメントアウトするか、リフレッシュ時だけ一時的にコメントアウトしてから `source ~/.zshrc` → `gh auth refresh ...` を実行します。 > > 更新後に `gh auth status` を実行し、`Token: ... workflow` と表示されればリフレッシュ成功です。その上で再度 `bun run release` などを実行すると、Release Action の dispatch が可能になります。 言われるがままに権限をつけてみる。 ```console unset GITHUB_TOKEN gh auth refresh -h github.com -s repo -s workflow ``` でも変わらず。。 `GITHUB_TOKEN` が優先されてしまうから、それを切らないとダメか。。 このあとも色々やりとりはあったけど、全部載せるときりが無いので過程は省略。 ## リリーススクリプトを実行する ```console bun run release ``` 以下は出力。 ```console $ bun scripts/release.mts === Silhouette リリース自動化 === ✅ 未pushコミットはありません。 🔍 Testsワークフローの最新結果を確認します... ✅ Testsワークフローの最新実行は成功しています。 🚀 Releaseワークフローを実行します... ℹ️ Releaseワークフロー run_id=17946291666 を検知しました。 ⏳ Releaseワークフロー実行中... status=in_progress, updated_at=2025-09-23T12:33:10Z ⏳ Releaseワークフロー実行中... status=in_progress, updated_at=2025-09-23T12:33:10Z ⏳ Releaseワークフロー実行中... status=in_progress, updated_at=2025-09-23T12:33:10Z ⏳ Releaseワークフロー実行中... status=in_progress, updated_at=2025-09-23T12:33:10Z ⏳ Releaseワークフロー実行中... status=in_progress, updated_at=2025-09-23T12:33:10Z ✅ Releaseワークフローが正常終了しました。 ✅ 新しいリリース 0.30.0 を確認しました。 ℹ️ リリースノートに関連Issue番号は見つかりませんでした。 === Bluesky投稿案 === 📦 Silhouette 0.30.0 🚀 ・**time:** 計測ステータス変更時にチェックリストのマークも変更するオプション・機能を追加 ・**time:** 計測ステータス変更時にチェックリストのマークも変更するオプション・機能を追加 ・**time:** 『ステータスバーに計測時間を表示する』が無効の場合にPush timerコマンドを実行するとエラーで処理が中断する https://github.com/tadashi-aikawa/silhouette/releases/tag/0.30.0 === 投稿案ここまで === 🔄 git pull を実行してリポジトリを最新化します... ❌ リリース処理中にエラーが発生しました: コマンド実行に失敗しました: git pull --ff-only origin master From github.com:tadashi-aikawa/silhouette * branch master -> FETCH_HEAD 9f33a72..7a120ff master -> origin/master error: Your local changes to the following files would be overwritten by merge: package.json Please commit your changes or stash them before you merge. Aborting ``` `git pull` はこちらの問題なので気にしなくてOK。 ``` 📦 Silhouette 0.30.0 🚀 計測ステータス変更時にチェックリストのマークも変更するオプション・機能を追加しました。 https://github.com/tadashi-aikawa/silhouette/releases/tag/0.30.0 ```