Release Workflow

リリースワークフロー

バージョン提案 → ユーザー承認 → リリース作成までの標準フローを定義する。

フロー概要

0.5. バージョン整合性チェック（ハードコード検出）
   ↓
1. バージョン提案（Sisyphusが自動計算）
   ↓
2. ユーザーがバージョンを承認/変更
   ↓
3. リリース実行（自動）
   - ハードコードバージョン修正（検出時）
   - バージョンファイル更新
   - CHANGELOG.md更新
   - コミット & タグ作成
   - push
   - GitHub Release作成
   - Release Workflow完了待機

実装環境

container-use不要

リリースワークフローではcontainer-useは不要です。

ホスト環境で直接実行

# リリース作業はホスト環境で直接実行
git add Cargo.toml CHANGELOG.md
git commit -m "chore: release v<version>"
git tag -a v<version> -m "Release v<version>"
git push origin <default-branch> --tags
gh release create v<version> ...

対応エコシステム

自動検出の優先順位

1. Cargo.toml → Rust
2. package.json → Node.js
3. pyproject.toml → Python (pyproject)
4. setup.py → Python (setup.py)
5. go.mod → Go
6. VERSION → Generic
7. いずれもなし → Tag-only

Note: 複数のエコシステムファイルが存在する場合、上記の優先順位で最初にマッチしたものを使用します。 スクリプトは検出時に警告を表示します。

Phase 0.5: バージョン整合性チェック

リリース前にコードベース内のハードコードされたバージョンを検出し、修正を提案する。

0.5.1 目的

• ハードコードされたバージョン文字列の検出
• 推奨パターン（動的バージョン取得）への移行提案
• リリース時のバージョン不整合を防止

0.5.2 エコシステム別チェックパターン

Rust

Node.js

Python

Go

0.5.3 共通チェックパターン（全エコシステム）

0.5.4 スクリプト実行

バージョン整合性チェックは release.sh に統合されています：

# Phase 0.5 のみ実行
.opencode/skill/release-workflow/scripts/release.sh --version-check <new-version>

# 完全リリースフロー内で自動実行（デフォルト）
.opencode/skill/release-workflow/scripts/release.sh --version 1.2.3

# Phase 0.5 をスキップして実行
.opencode/skill/release-workflow/scripts/release.sh --version 1.2.3 --skip-version-check

依存: rg（ripgrep）がインストールされている場合は高速検索を使用。 未インストールの場合は grep -E にフォールバック。

0.5.5 出力フォーマット

## バージョン整合性チェック結果

### ⚠️ 検出されたハードコードバージョン

| ファイル | 行 | 現在の値 | 種別 | 推奨対応 |
|---------|-----|---------|------|---------|
| src/cli/args.rs | 5 | `version = "0.1.0"` | Rust/clap | `#[command(version)]` に変更 |
| README.md | 12 | `badge/v0.1.0` | バッジ | `v{NEW_VERSION}` に更新 |

### 対応オプション

1. **自動修正を適用** → 推奨パターンに変換（コード変更あり）
2. **バージョン番号のみ更新** → 現在のパターンを維持し値のみ更新
3. **スキップ** → 警告のみ、修正なし

> 番号を選択してください（1-3）:

0.5.6 自動修正ルール

0.5.7 Phase 0.5 スキップ条件

以下の場合はPhase 0.5をスキップ可能：

• --skip-version-check フラグ指定時
• 前回リリースからコード変更がない場合（CHANGELOG.mdのみ等）
• ユーザーが明示的にスキップを選択

Phase 1: バージョン提案

1.1 エコシステム検出とバージョン取得

# スクリプトを使用（推奨）
.opencode/skill/release-workflow/scripts/release.sh --detect

# または手動で検出
# Rust
grep '^version = ' Cargo.toml | head -1 | sed 's/version = "\(.*\)"/\1/'

# Node.js
jq -r '.version' package.json

# Python (pyproject.toml)
grep '^version = ' pyproject.toml | head -1 | sed 's/version = "\(.*\)"/\1/'

# Python (setup.py)
grep -o "version=['\"][^'\"]*['\"]" setup.py | sed "s/version=['\"]\\([^'\"]*\\)['\"/\\1/"

# Go / Tag-only
git tag --sort=-version:refname | head -1 | sed 's/^v//'

# Generic
cat VERSION

1.2 変更内容の分析

# 前回リリースからのコミットを取得
git log <last-tag>..HEAD --oneline

1.3 セマンティックバージョニング判定

1.4 提案フォーマット

## リリース提案

### エコシステム
<detected-ecosystem>

### 現在のバージョン
v0.4.0

### 前回リリースからの変更
- feat: 新機能追加（#XX）
- fix: バグ修正（#YY）

### 提案バージョン
**v0.5.0** (MINOR: 新機能追加)

### 変更種別
- ✨ 新機能: N件
- 🐛 バグ修正: N件
- 📝 ドキュメント: N件

---

**このバージョンでリリースしますか？**

1. **提案バージョンで続行** → v0.5.0 でリリース開始
2. **バージョン変更** → 手動でバージョンを入力
3. **キャンセル** → リリース中止

> 番号を選択してください（1-3）:

参照: {{skill:approval-gate}} 形式に準拠

Phase 2: ユーザー承認

ユーザーがバージョンを承認または変更するまで待機。

Phase 3: リリース実行

3.1 バージョンファイル更新

# スクリプトを使用（推奨）
.opencode/skill/release-workflow/scripts/release.sh --update-version <new-version>

# または手動で更新（エコシステム別）

Rust (Cargo.toml)

sed -i '' 's/^version = ".*"/version = "<new-version>"/' Cargo.toml

Node.js (package.json)

npm version <new-version> --no-git-tag-version
# または
jq '.version = "<new-version>"' package.json > tmp.json && mv tmp.json package.json

Python (pyproject.toml)

sed -i '' 's/^version = ".*"/version = "<new-version>"/' pyproject.toml

Python (setup.py)

sed -i '' "s/version=['\"][^'\"]*['\"]/version='<new-version>'/" setup.py

Generic (VERSION)

echo "<new-version>" > VERSION

Go / Tag-only

バージョンファイル更新なし（タグのみ）

3.2 CHANGELOG.md更新

変更内容を ## [Unreleased] の下に追加：

## [<new-version>] - <YYYY-MM-DD>

### Added
- 機能追加項目

### Fixed
- バグ修正項目

### Changed
- 変更項目

3.3 コミット & タグ作成

# スクリプトを使用（推奨）
.opencode/skill/release-workflow/scripts/release.sh --commit <new-version>

# または手動
git add -A
git commit -m "chore: release v<new-version>"
git tag -a v<new-version> -m "Release v<new-version> - <summary>"
git push origin <default-branch> --tags

3.4 GitHub Release作成

# スクリプトを使用（推奨）
.opencode/skill/release-workflow/scripts/release.sh --create-release <new-version> "<release-notes>"

# または手動
gh release create v<new-version> \
  --title "v<new-version> - <summary>" \
  --notes "<release-notes>"

3.5 Release Workflow完了待機

# スクリプトを使用（推奨）
.opencode/skill/release-workflow/scripts/release.sh --watch

# または手動
gh run list --workflow=Release --limit 1
gh run watch <run-id>

3.6 リリースアセット確認

gh release view v<new-version> --json tagName,assets --jq '.tagName, (.assets[].name)'

スクリプト使用方法

.opencode/skill/release-workflow/scripts/release.sh を使用することで、上記の処理を自動化できます。

基本コマンド

# エコシステム検出とバージョン表示
.opencode/skill/release-workflow/scripts/release.sh --detect

# 完全自動リリース（対話モード）
.opencode/skill/release-workflow/scripts/release.sh

# バージョン指定リリース
.opencode/skill/release-workflow/scripts/release.sh --version 1.2.3

# ドライラン（実行せずに確認）
.opencode/skill/release-workflow/scripts/release.sh --dry-run --version 1.2.3

個別操作

# バージョン更新のみ
.opencode/skill/release-workflow/scripts/release.sh --update-version 1.2.3

# コミット & タグのみ
.opencode/skill/release-workflow/scripts/release.sh --commit 1.2.3

# GitHub Release作成のみ
.opencode/skill/release-workflow/scripts/release.sh --create-release 1.2.3 "Release notes here"

# Workflow監視
.opencode/skill/release-workflow/scripts/release.sh --watch

リリースノートテンプレート

## <project-name> v<version>

### ✨ 新機能

#### <機能名>
<説明>

### 🐛 バグ修正

- <修正内容> (#<issue-number>)

### 📝 ドキュメント

- <ドキュメント変更>

---

### インストール方法

```bash
# エコシステムに応じたインストールコマンド

動作確認

<command> --version

システム要件

• <要件>

---

## CHANGELOG.md テンプレート

```markdown
## [<version>] - <YYYY-MM-DD>

### Added
- **<機能名>**: <説明> (#<issue>)
  - <詳細1>
  - <詳細2>

### Fixed
- **<修正名>**: <説明> (#<issue>, #<pr>)

### Changed
- **<変更名>**: <説明>

### Deprecated
- **<非推奨名>**: <説明>

### Removed
- **<削除名>**: <説明>

### Security
- **<セキュリティ修正>**: <説明>

エラーハンドリング

タグが既に存在する場合

# エラー: tag 'v0.5.0' already exists
git tag -d v<version>  # ローカル削除
git push origin :refs/tags/v<version>  # リモート削除
# 再度タグ作成

Release Workflow失敗時

# ワークフロー再実行
gh run rerun <run-id>

# または手動でリリースアセットをアップロード
gh release upload v<version> <asset-file>

チェックリスト

リリース前

• 全テスト通過
• Lint通過
• デフォルトブランチが最新
• 未マージのPRなし
• バージョン整合性チェック完了（Phase 0.5）

リリース中

• ハードコードバージョン修正（検出時）
• バージョンファイル更新
• CHANGELOG.md更新
• コミット & タグ作成
• push完了
• GitHub Release作成

リリース後

• Release Workflow完了
• アセットが正しくアップロード
• リリースノートの内容確認

関連ドキュメント

変更履歴