# バッチ設計書 31-rake composetest

## 概要

本ドキュメントは、mrubyプロジェクトにおけるRakeタスク `rake composetest` のバッチ設計書である。docker-composeを使用してコンテナ環境内でmrubyのビルドおよびテストを実行するタスクについて記述する。

### 本バッチの処理概要

`rake composetest` は、Docker Composeを利用してコンテナ化された環境内でmrubyの全テストをビルド・実行するRakeタスクである。ホスト環境に依存せず、統一された環境でテストを実行できる。

**業務上の目的・背景**：開発者のローカル環境の差異（OS、コンパイラバージョン、依存ライブラリ等）によるテスト結果のばらつきを排除し、再現性のあるテスト環境を提供する。CI/CDパイプラインと同等の環境をローカルで再現するために必要なタスクである。

**バッチの実行タイミング**：開発者が手動で任意のタイミングで実行する。特に、コミット前の最終確認やCI環境と同等の条件でのテスト実行が必要な場合に使用される。

**主要な処理内容**：
1. docker-composeコマンドを使用してプロジェクト名「mruby」でtestサービスを起動
2. コンテナ内で `rake deep_clean` を実行し、既存のビルド成果物を全て削除
3. コンテナ内で `rake -m test:run:serial` を実行し、全テストを逐次ビルド・実行
4. テスト完了後、コンテナを停止

**前後の処理との関連**：本タスクは独立して実行可能であり、前提となるバッチはない。ただし、Dockerイメージが事前にビルドされている必要がある（docker-composeが自動ビルドを行う）。No.30 `rake composecheck` と同じDockerインフラを共有する。

**影響範囲**：コンテナ内部のビルドディレクトリのみに影響し、ホスト環境のファイルシステムには影響しない。Docker Composeによりコンテナが起動・停止される。

## バッチ種別

テスト実行（Docker環境）

## 実行スケジュール

| 項目 | 内容 |
|-----|------|
| 実行頻度 | 随時 |
| 実行時刻 | 任意 |
| 実行曜日 | N/A |
| 実行日 | N/A |
| トリガー | 手動（開発者によるコマンド実行） |

## 実行条件

### 前提条件

| 条件 | 説明 |
|-----|------|
| Docker | Dockerデーモンが起動していること |
| docker-compose | docker-composeコマンドが利用可能であること |
| Dockerfile | プロジェクトルートにDockerfileが存在すること |
| docker-compose.yml | プロジェクトルートにdocker-compose.ymlが存在すること |

### 実行可否判定

docker-composeコマンドが利用可能であり、Dockerデーモンが起動している場合に実行可能。Rakefileの `composetest` タスク定義により、`sh "docker-compose -p mruby run test"` が実行される。

## 入力仕様

### 入力パラメータ

| パラメータ名 | 型 | 必須 | デフォルト値 | 説明 |
|-------------|-----|-----|-------------|------|
| MRUBY_CONFIG | 環境変数 | No | ci/gcc-clang | mrubyビルド設定ファイルパス（docker-compose.yml内で設定） |
| CC | 環境変数 | No | gcc | Cコンパイラ（docker-compose.yml内で設定） |
| CXX | 環境変数 | No | g++ | C++コンパイラ（docker-compose.yml内で設定） |
| LD | 環境変数 | No | gcc | リンカ（docker-compose.yml内で設定） |
| SKIP | 環境変数 | No | check-executables-have-shebangs | スキップするpre-commitフック |

### 入力データソース

| データソース | 形式 | 説明 |
|-------------|------|------|
| Dockerfile | Docker設定 | コンテナイメージのビルド定義 |
| docker-compose.yml | YAML | サービス構成定義 |
| Rakefile | Ruby | Rakeタスク定義 |
| mrubyソースコード一式 | C/Ruby | テスト対象のソースコード |

## 出力仕様

### 出力データ

| 出力先 | 形式 | 説明 |
|-------|------|------|
| 標準出力 | テキスト | テストの実行結果（成功/失敗の詳細） |
| コンテナ内ビルドディレクトリ | バイナリ/オブジェクトファイル | ビルド成果物（コンテナ破棄時に消失） |

### 出力ファイル仕様

コンテナ内で生成されるビルド成果物はコンテナのライフサイクルに依存する。ホスト側にはテスト結果の標準出力のみが出力される。

| 項目 | 内容 |
|-----|------|
| ファイル名 | N/A（標準出力のみ） |
| 出力先 | 標準出力 |
| 文字コード | UTF-8 |
| 区切り文字 | N/A |

## 処理フロー

### 処理シーケンス

```
1. Rakeタスク起動
   └─ `rake composetest` コマンドを実行
2. docker-composeコマンド実行
   └─ `docker-compose -p mruby run test` をシェル経由で実行
3. Dockerイメージビルド（未ビルドの場合）
   └─ Dockerfileに基づきruby:3.2.2-bullseyeベースのイメージを構築
4. コンテナ起動
   └─ 作業ディレクトリ /app でtestサービスを起動
5. deep_clean実行
   └─ コンテナ内で `rake deep_clean` を実行し、全ビルド成果物を削除
6. テストビルド・実行
   └─ `rake -m test:run:serial` で全テストを逐次ビルド・実行
7. コンテナ停止
   └─ テスト完了後、コンテナを停止
```

### フローチャート

```mermaid
flowchart TD
    A[rake composetest 開始] --> B[docker-compose -p mruby run test 実行]
    B --> C{Dockerイメージ存在?}
    C -->|なし| D[Dockerイメージビルド]
    C -->|あり| E[コンテナ起動]
    D --> E
    E --> F[rake deep_clean 実行]
    F --> G[rake -m test:run:serial 実行]
    G --> H{テスト結果}
    H -->|成功| I[正常終了・コンテナ停止]
    H -->|失敗| J[エラー出力・コンテナ停止]
    I --> K[バッチ終了]
    J --> K
```

## データベース操作仕様

### 操作別データベース影響一覧

本バッチではデータベース操作は行わない。

| 処理 | 対象テーブル | 操作種別 | 概要 |
|-----|-------------|---------|------|
| N/A | N/A | N/A | データベース操作なし |

### テーブル別操作詳細

該当なし。

## エラー処理

### エラーケース一覧

| エラーコード | エラー種別 | 発生条件 | 対処方法 |
|------------|----------|---------|---------|
| 非0終了 | Docker未起動 | Dockerデーモンが起動していない | Dockerデーモンを起動する |
| 非0終了 | docker-compose未インストール | docker-composeコマンドが見つからない | docker-composeをインストールする |
| 非0終了 | イメージビルド失敗 | Dockerfileのビルドに失敗 | Dockerfileの内容やネットワーク接続を確認する |
| 非0終了 | テスト失敗 | テストケースの失敗 | テスト結果の出力を確認し、失敗原因を特定する |
| 非0終了 | ビルド失敗 | コンパイルエラー | ソースコードのエラーを修正する |

### リトライ仕様

| 項目 | 内容 |
|-----|------|
| リトライ回数 | 0（自動リトライなし） |
| リトライ間隔 | N/A |
| リトライ対象エラー | N/A |

### 障害時対応

バッチ失敗時は、標準出力・標準エラー出力のログを確認し、失敗原因を特定する。コンテナの状態は `docker-compose -p mruby ps` で確認可能。残存コンテナは `docker-compose -p mruby down` で削除できる。

## トランザクション仕様

| 項目 | 内容 |
|-----|------|
| トランザクション範囲 | N/A（データベーストランザクションなし） |
| コミットタイミング | N/A |
| ロールバック条件 | N/A |

## パフォーマンス要件

| 項目 | 内容 |
|-----|------|
| 想定処理件数 | mruby全テストスイート |
| 目標処理時間 | 特に定めなし（初回イメージビルド時は数分、テスト実行は環境依存） |
| メモリ使用量上限 | Dockerコンテナのデフォルトメモリ制限に依存 |

## 排他制御

docker-composeのプロジェクト名 `mruby` で管理されるため、同一プロジェクト名で同時実行した場合はコンテナ名の競合が発生する可能性がある。同時実行は避けるべきである。

## ログ出力

| ログ種別 | 出力タイミング | 出力内容 |
|---------|--------------|---------|
| 開始ログ | docker-compose起動時 | コンテナ起動メッセージ |
| 進捗ログ | テスト実行中 | 各テストケースの実行結果 |
| 終了ログ | テスト完了時 | テスト結果サマリー |
| エラーログ | エラー発生時 | エラー詳細メッセージ |

## 監視・アラート

| 監視項目 | 閾値 | アラート先 |
|---------|-----|----------|
| 処理時間 | 特に定めなし | 標準出力 |
| エラー件数 | 1件以上 | 標準エラー出力 |

## 備考

- Dockerコンテナのベースイメージは `ruby:3.2.2-bullseye` である
- コンテナ内では `ci/gcc-clang` 設定ファイルを使用し、GCCでビルドを行う
- `SKIP=check-executables-have-shebangs` 環境変数により、pre-commitフックの一部がスキップされる
- コンテナの作業ディレクトリは `/app` に設定されている
- テスト実行前に `deep_clean` が行われるため、常にクリーンな状態からビルド・テストが実行される
