CI とリリース

stepper リポジトリは、継続的インテグレーション、手動ワークフロー実行、自動化されたリリース配布に GitHub Actions を使用します。3 つのワークフローが、各プラットフォームでのビルド、テスト、バイナリの公開を担います。

ci.yml — push 時のビルドとテスト

コードベースを検証するため、すべての push と pull request で実行されます。このワークフローは以下の品質ゲートを実行します:

• build — cargo build --workspace でワークスペースをコンパイルします
• clippy -D warnings — 警告をエラーとして扱うモードで clippy リンターを実行し、コード品質を強制します
• test — cargo test --workspace を実行します(#[ignore] でマークされた、または環境によってゲートされるライブテストはスキップされます)
• install — scripts/install.sh を実行してインストールスクリプトが正しく動作するか検証するスモークテストです

run.yml — 手動ヘッドレス実行

オンデマンドのテスト実行のために workflow_dispatch でトリガーされる手動ワークフローです。このワークフローは stepper をビルドおよびインストールした後、ユーザーが指定した入力でヘッドレス実行します。

• 3 つのワークフロー入力を受け取ります: prompt(ヘッドレスプロンプト)、model(使用するモデル ID)、mode(権限モード)
• プロバイダー認証には STEPPER_<PROVIDER>_API_KEY という名前のリポジトリシークレットを使用します(例: STEPPER_ANTHROPIC_API_KEY)

release.yml — クロスプラットフォーム公開

prod ブランチへの push または手動ワークフロー dispatch でトリガーされます。このワークフローは品質チェックの合格をゲートとし、最適化されたリリースバイナリをビルドして GitHub Release に公開します。

品質ゲート

• build — cargo build --workspace でコンパイルします
• clippy -D warnings — 警告ゼロを強制します
• test — テストスイート全体を実行します

リリースアーティファクト

このワークフローは 3 つのターゲットプラットフォーム向けのバイナリをビルドして公開します:

• macOS arm64 (Apple Silicon)
• Linux x86_64
• Windows x86_64

各ターゲットについて、バージョン付きとバージョンなしの両方のアーカイブを公開します:

• バージョン付き: stepper-<version>-<target>.tar.gz または .zip(名前にバージョンを含む)
• バージョンなし: stepper-<target>.tar.gz または .zip(静的ホスティング用の安定した URL)

アーカイブは v<version> のタグが付いた GitHub Release に公開され、バージョンは Cargo.toml のワークスペースバージョンから読み取られます。新しいリリースを作成するには Cargo.toml のバージョンを上げてください。同じバージョンを再 push すると、リリースアセットが更新されます。

配布

リポジトリは公開されているため、エンドユーザーは最新の GitHub リリースからバイナリを直接ダウンロードします。§1 で参照されているインストールスクリプト(別の stepper.gumyo.net サイトでホストされています)は、releases/latest/download からプラットフォーム固有のアーカイブを取得し、展開して stepper バイナリを ~/.local/bin にインストールします。