#463 を実装する（スプリント m8d）

[takemi-ohama]

VS Code Server の本体を全コンテナ共通の 1 本のボリュームに置き、本体だけを共有する構成にしました。コンテナの起動で bin を用意して古い版を片付け、起動の後の処理で bin の所有者を揃えます。up は旧形式のボリュームが残っていると案内します。スプリント m8d のブランチへ集める変更です（#463）。

利用者向けの変化

• VS Code Server の本体は全コンテナ共通の 1 本のボリュームに置かれ、各コンテナで共有されます。
• コンテナを起動すると VS Code Server の bin が用意され、古い版は片付けられます。
• 起動の後の処理で VS Code Server の bin の所有者が揃えられます。
• 旧形式の VS Code Server ボリュームが残っていると、devbase up がそのことを案内します。

移行の手順

• devbase: 移す操作はありません。旧形式の VS Code Server ボリュームの中身は共通のボリュームへ写しません。
• devbase: この版より前の版へ戻すと、消していない旧形式の VS Code Server ボリュームが前と同じように付きます。共通の VS Code Server ボリュームは残りますが、害はありません。

変更の要点

• lib/devbase/volume/compose.py・lib/devbase/volume/manager.py
  • VS Code Server の本体を全コンテナ共通の 1 本のボリュームに置きます。
• lib/devbase/editor/vscode_server.py
  • コンテナの起動で VS Code Server の bin を用意し、旧版を片付けます。
• lib/devbase/commands/container.py
  • 起動の後の処理で bin の所有者を揃えます。
  • up で旧形式のボリュームを案内します。
• 文書
  • docs/user/container-operations.md に、本体だけを共有する構成と移り方を書きました。
  • docs/specifications/post-start.md の起動の後の処理の順を、今の振る舞いに合わせました。
  • docs/user/troubleshooting.md の VS Code Server の困りごとの節を、今の振る舞いに合わせました。
• テスト
  • entrypoint、editor、volume、起動の後の処理のテストを追加・更新しました。

テスト

ステップ	結果
test-limited	ok：範囲テスト 1 本（123.6 秒、戦略 local-full）
design-tests	ok：設計文書 1 件（issues/issue-463-design.md）。設計に名前の出るテスト 1 件がすべて HEAD にある
design-specs	ok：変えたパス 14・シンボル 118 を含む既存の確定仕様と変更履歴 18 件

設計と違う点

• 無し

設計の決定と違えたところ

• manager.py の get_vscode_volume_for に加え、それだけが使っていた resolve_project_name・normalize_volume_component（と内部の定数）も消した。ほかに呼ぶところが無く、残すと使われないコードになるため。VolumeManager(project_name) と ensure_volumes(project_name=…) の引数は呼び出し側との互換のために残した（名前には使わない）
• 起動の後の処理の段の順を確かめる既存のテスト（tests/commands/test_container_scale_order.py）の期待の並びに、bao と窓のタイトルの間の vscode_bin（bin の所有者の直し）を足した。tests/commands/test_container_context.py は docker の呼び出しの数を見るため、bin の直しと旧形式の案内を差し替えた
• そのほかは設計どおり（名前 devbase_vscode-server-bin、残す版の数 5、product.json の更新時刻で並べる、60 分より古い展開の途中を消す、旧形式の案内は devbase up のたびに最後に出す）

手で確かめたこと（担当、2026-10-14）

手元の devbase-base:latest（sha256:e66aeb95…、作成 2026-10-12T17:19:13Z、arm64、macOS の Docker Desktop。この課題より前の entrypoint を持つ）を docker run --rm で、新しく作った空の作業用ボリューム（issue463f-bin・issue463f-bin2）を付けて打った。新しい entrypoint.sh は読み取り専用で付けて関数を呼んだ。既存の devbase_vscode_* は写さず・付けず・消していない。devbase up は打っていない。作業用のボリュームとコンテナは消した。

受け入れ条件	確かめ方	結果
4	コンテナ A で VS Code Server 1.141.1（arm64）を bin/<commit> に置き、別のコンテナ B（新しい devbase_setup_vscode_server_dir を通した）で bin/<commit>/bin/code-server --version	B で 1.141.1 と commit が出た
7〜9	bin/ に 40 桁の版を 8 つ（product.json を 1 か月ずつ古く、ディレクトリの更新時刻は逆向き）・実の版 1 つ・最も古く残る版に入れ子の本体・2 時間前と今の展開の途中のディレクトリを置き、新しい関数を 2 つのコンテナで同時に走らせた。5 回	5 回とも、残った版は product.json の新しい 5 つ、入れ子の本体と 2 時間前の展開の途中は消え、今の展開の途中は残り、WARNING は 0 行、両方の終了コード 0
10（新しい entrypoint）	空のボリュームを ~/.vscode-server/bin だけに付け、関数を通してから開発ユーザーで touch bin/x と mkdir data extensions	前は ~/.vscode-server と bin が root:root、後は ubuntu:ubuntu になり、どちらも通った
10（この課題より前の entrypoint）	イメージの今の entrypoint で起動（DEVBASE_ACCOUNT_GROUP=team-a）し、prepare_bin_dir をホストから打った	起動の後は bin が root:root で touch が Permission denied。prepare_bin_dir の後は ubuntu:ubuntu で書けた。2 回目も成功（何も変えない）

• containers/base/entrypoint.sh は devbase-base:latest の shellcheck で指摘 0 件
• 全体のテスト env -u DEVBASE_ROOT uv run --locked pytest tests/ -q は 4385 件通過・32 件スキップ。uvx ruff check --select=E9,F63,F7,F82 lib は通過

手動確認

• M1（マージ前。conductor が P3 の承認を取ってから行う。担当は行っていない）: 新しい devbase で別のプロジェクトの 2 つのコンテナを devbase up し、base と派生イメージを建て直す前のイメージのまま VS Code を attach する。2 つ目の attach が本体を取り直さず共通の devbase_vscode-server-bin の bin/<commit> で繋がる。両方の窓が使え、窓のタイトルがそれぞれのコンテナ名で始まり、片方の窓の「ウィンドウの再読み込み」で同じコンテナへ繋がり直す。片方のプロジェクトで devbase up を打ち直した後に attach し直すと、Dev Containers の既定の拡張機能が入り直して使える（入り直しにかかった時間を記録する）。devbase up の最後に旧形式の devbase_vscode_* の名前と docker volume rm の行が出る
• M4（リリース後）: 片方の端末の VS Code だけを更新し、版の違う 2 つの窓が同じ bin/ を使う。どちらも使え、起動の片付けがどちらの版も消さない
• M5（リリース後）: VS Code の更新の後に複数の窓を一度に開き直し、その後にコンテナを起動し直すと、bin/<新しい commit>/ に入れ子の本体が残っていない

残した事項

• docs/user/troubleshooting.md（437〜457 行・487 行付近）に、コンテナごとの devbase_vscode_{project}_{index} を前提にした記述（ボリュームが増える件の説明と、devbase_vscode_<project>_1 -> /home/ubuntu/.vscode-server のマウントの確かめ方）が残っている。この作業の触る範囲の外のため直していない。別の課題か、この PR の範囲を広げて直す
• 本体の旧版の片付けは base と派生イメージを建て直した後から効く。それまでは共通のボリュームの bin/ に版が溜まる（1 本分）

モード: standard / 通した工程: 実装 → 完了判定 → Pull Request

🤖 Generated with Claude Code