| name | debug-release-ci |
| description | Grimodex の Electron release workflow、tag build、署名、公証、 installer migration、artifact 集約、publish の失敗を、version と tag を増やさず診断・修正する。 「release CI失敗」「release workflow失敗」「tag build失敗」「署名／公証エラー」 「packaging失敗」「publish失敗」「成功済みplatformを再buildしたくない」で使用する。
|
Debug Release CI
Releaseをデバッグ用テストハーネスとして使わない。失敗runと修正HEADを固定し、最小再現、対象stageだけのhosted gate、修正のmergeを先に完了する。正式なversion bumpとtagは最後に一度だけ行う。
責務境界
- Electron release workflow、tag build、署名、公証、Windows installer migration、artifact集約、Tauri bridge、GitHub Release publishの失敗だけを扱う。
- 一般のPR／master CI、型エラー、製品コードの単体テスト失敗は
/debug-issue へ渡す。
package.json、release notes、version、既存tagは変更しない。診断のためだけに新しいpatch versionやtagを作成しない。- 既存tagを移動、削除、上書きしない。失敗したtagから次のpatch bumpへ再帰しない。
- 修正済みclean branchのPR／mergeは
/ship-branch、focused gateとmerge完了後のDraft Release準備だけを /bump-version へ渡す。
1. 失敗状態を固定する
変更や再実行の前に、次を記録する。
- workflow run ID、run attempt、tag／ref
- head SHA
- 失敗jobとstep、最初の有効なエラー
- 成功済みjob、platform、artifact名
- artifactの期限と、source runが同じworkflow path／tag／head SHA／versionに属する証拠
- queue／runner／外部API／secret／workflow／コードのどこで失敗したか
gh run view <run-id> --json ... と失敗jobのlogを使い、推測で分類しない。同じrunの途中結果を、別SHAの結果と混ぜない。
2. 再実行か修正かを分類する
- runner切断、外部サービスの一時障害、artifact伝播遅延など、コード変更不要で同一SHAの再実行に意味がある場合だけ
gh run rerun <run-id> --failed を使う。
- workflow、script、package、署名前提、secret契約の修正が必要ならfailed-only rerunでは直らない。修正branchで原因に最も近いcontract testを先にredにし、修正後greenにする。
- 既に成功したplatformは再実行しない。shared native code、lockfile、共通packaging設定を変えた場合だけ、影響範囲を明示して対象を広げる。
- full Release workflowを最初の再現手段にしない。
3. Targeted Release CIを使う
.github/workflows/release.yml の手動実行はdebug専用で、publish=false以外を拒否する。workflow自体は常にtrusted default branchからdispatchし、candidate_refを別に渡す。未mergeのWindows／Linux修正は、originに存在する40桁commit SHAだけをcandidate_refに指定する。gateは指定SHAとcheckout結果の一致を検証し、そのSHAだけをbuild jobがcheckoutする。
| target | 実行場所 | 用途 |
|---|
windows | workflow=master、candidate=修正commitの40桁SHA | Windows package、未署名契約、実installer migration |
linux | workflow=master、candidate=修正commitの40桁SHA | Linux package、ABI、deb／rpm契約 |
mac | workflow／candidateともtrusted default branch | production Apple secretsを使う署名・公証付きmacOS build |
publish | workflow／candidateともtrusted default branch | source_run_idの成功済みhost artifactを再利用したread-only publish dry-run |
all | workflow／candidateともtrusted default branch | 全3 hostと早期bridge signing preflight。releaseは作成しない |
Windows／Linuxは修正commitをoriginへpushし、その40桁SHAを固定してcandidate_refに渡す。branch名や短縮SHAは渡さない。dispatchで返るrun URL／IDを記録し、gate logのresolved candidate SHAが指定SHAと一致することを確認する。手動runはtrusted default branchのworkflow定義とresolverを使い、candidate側の.github/workflows/release.ymlは実行しない。workflow YAML自体の修正はcontract testを通してmergeした後、candidate_ref=masterでhosted gateを実行する。
mac／publish／allはproduction secretをbranch codeへ渡さないため、focusedなlocal／contract検証後に修正を /ship-branch でdefault branchへmergeしてから実行する。candidateのpackage.json versionがdefault branchから変わっている場合もgateは拒否する。
例:
gh workflow run release.yml \
--ref master \
-f target=windows \
-f publish=false \
-f candidate_ref=<40-character-fix-commit-sha>
gh workflow run release.yml \
--ref master \
-f target=publish \
-f publish=false \
-f candidate_ref=master \
-f source_run_id=<failed-release-run-id>
target=publish はsource runが正規の.github/workflows/release.yml、対象tag／SHA、またはtrusted default-branch debug runに属することを検査してからhost artifactをdownloadする。artifact名とversionの完全性を検証し、署名、signature検証、latest.json生成まで行うが、GitHub Releaseの作成・更新・uploadは行わない。source artifactが期限切れの場合だけ、target=allをdefault branchで実行し、そのrun IDを新しいsource_run_idとして使う。
4. 修正と証跡を閉じる
Windows／Linux
- 原因に対応する最小test／commandをgreenにする。
- script／package修正ならcandidate SHAを固定し、対象platformのtargeted workflowをそのSHAでgreenにする。workflow YAML／job control／permissions／matrixの修正ならcontract test後に先にmergeし、default branch SHAでhosted gateを通す。
- run ID、candidate SHA、target、成功job、元runの成功済みjobを記録する。別SHAの結果を「1つのgreen release」と表現しない。
- PR／mergeが依頼範囲なら、ユーザー差分を混ぜずfix commitを作り、
/ship-branchへ失敗run、原因、成功済みjob、focused gate、fix commit SHAを渡す。依頼範囲外なら証跡を報告して停止する。
mac／publish／all
- 原因に対応する最小test／commandをgreenにする。
- PR／mergeが依頼範囲ならfix commitを
/ship-branchでdefault branchへmergeする。権限がなければ、secret-backed gateや/bump-versionへ進まずhandoff地点を報告する。
- merge後のdefault branch SHAを固定し、
candidate_ref=masterで対象targetをgreenにする。
- run ID、candidate SHA、target、成功job、再利用したsource_run_idとそのtag／SHA／artifact期限を記録する。
どちらの経路でも、元のゴールがrelease準備までの場合だけ、fixがorigin/masterに含まれfocused gateが成功した後 /bump-version へ渡す。version bump、tag、full release workflow、Draft Release組み立てはここで一度だけ行い、Releaseは公開しない。
停止条件
- run ID、head SHA、失敗stepを固定できない
- workflow dispatchの
--refがdefault branch以外、未mergeのWindows／Linux修正のcandidate_refが40桁SHA以外、またはsecret-backed targetのcandidate_refがdefault branch以外
publish=true、tag移動、既存releaseの破壊的変更が必要- source artifactが不足・期限切れで、再build範囲を広げる根拠を説明できない
- focused gateが失敗中
- secret-backed gateのfix commitが未mergeで、
/ship-branchへ進む権限もない
停止時は、成功済みjobを含む現在状態、足りない証跡、次に必要な最小操作を報告する。
