[miyamoto83]

Purpose

RDM-waterbutler と RDM-modular-file-renderer の Python 3.13 化(それぞれ別 PR)により、両イメージは実行イメージに pip を含まず、依存ライブラリを焼き込んだ構成になる。現行の E2E は RDM-osf.io の docker-compose.yml にある wb_requirements / mfr_requirements(Python 3.6 / 3.5 のパスで invoke install を実行し、ボリュームへ展開する)をそのまま使うため、これらのイメージでは起動できない。また MFR は Office 系ファイルの変換を Celery ワーカー経由で unoserver に依頼する方式になるため、E2E 環境にもその 2 サービスが必要になる。

本 PR では、E2E が WaterButler / MFR イメージの依存の持ち方をイメージ自身から判定して docker-compose の override を生成するようにする。公開イメージ(:latest)が Python 3.13 版に切り替わった後も、両リポジトリのブランチを指定した検証でも、同じワークフローで実行できる。あわせて、MFR の動作を直接確認するためのファイルプレビューのテスト手順を追加する。

Changes

• build-images ジョブに WaterButler / MFR イメージの「依存レイアウト」の判定を追加した。イメージに 2 つの事実を問い合わせる。(1) sysconfig の purelib の親ディレクトリ(例 /usr/local/lib/python3.13)、(2) python3 -m pip --version が通るか。pip があれば legacy(現行どおり invoke install で requirements ボリュームへ展開)、なければ bundled(イメージ内のライブラリツリーをボリュームへコピー)として扱う。Python の版はキーにしないため、3.14 以降への移行でもワークフローの変更は不要。
• setup_rdm.sh の create_docker_override を、判定結果(WB_LAYOUT / WB_LIBDIR / MFR_LAYOUT / MFR_LIBDIR)に従って override を生成するように変更した。bundled では requirements ボリューム名にライブラリディレクトリ名を含め(例 wb_requirements_3_13_vol)、旧イメージで作られたボリュームが新イメージにマウントされないようにする。legacy では、イメージのライブラリディレクトリが RDM-osf.io の compose 定義のマウント先(WaterButler /usr/local/lib/python3.6、MFR /usr/local/lib/python3.5)と一致しない場合は明示的にエラーにする。
• MFR が bundled のとき、mfr_worker(Celery)と unoserver のサービスを override に追加し、MFR の env に broker と unoserver の接続先を追記する。unoconv コンテナは使わない。
• MFR のソースから E2E 用イメージをビルドできるようにした(MFR_REPOSITORY / MFR_BRANCH。WaterButler と同じ方式)。このとき Dockerfile.unoserver から unoserver イメージも同時にビルドする。公開 MFR イメージが bundled で UNOSERVER_IMAGE が未指定のときは、MFR リポジトリの develop から unoserver イメージをビルドする。公開 unoserver イメージが無いための措置で、公開イメージができれば UNOSERVER_IMAGE の既定値をそれに向けることもできる。
• MFR / WaterButler のイメージ・リポジトリ・ブランチを、PR 本文と workflow_dispatch の両経路とも build-images で一度だけ解決し、ジョブ出力で各 E2E ジョブへ渡すようにした。従来は各ジョブで個別に解決していた。
• RDM-osf.io の env ファイルが有効にする MFR の EXTENSION_CONFIG_LOCAL_DEVELOPMENT を E2E では無効にした。有効のままだと PDF や動画のプレビューがファイルを localhost:7777 から取りに行き、ブラウザのセッション無しで WaterButler に当たって 401 になる。
• ファイルプレビューのテスト手順 テスト手順-ストレージ共通-ファイルプレビュー.ipynb、共通アサーション scripts/mfr_preview.py、試験データ testdata/mfr-preview/(txt / png / jpg / pdf / docx / pptx / csv / xlsx / webm。個人情報・外部サービスへの参照なし)を追加した。run_tests.py の mfr_preview_enabled で実行し、User Tests ジョブでは legacy・bundled のどちらのレイアウトでも実行する。legacy では RDM-osf.io の compose 定義にある unoconv を起動して Office 文書の変換を行う(従来の E2E は起動していなかった)。
• PR テンプレートに MFR_REPOSITORY / MFR_BRANCH / UNOSERVER_IMAGE / WB_REPOSITORY / WB_BRANCH を追加した。

公開イメージ(legacy)に対する既定動作は、EXTENSION_CONFIG_LOCAL_DEVELOPMENT の無効化を除き従来と同じ override になる。

Ticket

Note

• 公開イメージ(legacy)での実行と、Python 3.13 版の WaterButler・MFR をブランチ指定でビルドした実行(bundled)の両方を、本 PR と同一内容のコミットで確認した(実行 40277254892、実行 40277519350)。ファイルプレビューの試験は両方で通過。失敗 3 件(Metadata・Wiki・Migration 20250906)は MFR / WaterButler を経由しない。
• 依存レイアウトはイメージの 2 つの事実から推定し、compose の配線(ボリュームのマウント先、起動コマンド、追加サービス)は setup_rdm.sh 側に持つ。RDM-osf.io の docker-compose.yml の Python パス直書きが変われば、legacy の照合値もそれに合わせる。
• RDM-osf.io の docker-compose を Python 3.13 版イメージに追随させる際は、requirements ボリュームを使わず依存を焼き込んだイメージをそのまま使う構成も選択肢になる。その場合はこの判定自体が不要になる。

Custom Test Configuration

Python 3.13 版の WaterButler・MFR をそれぞれの作業ブランチ(miya-biz フォーク)からビルドしたイメージを対象に PR CI を実行する。

• RDM_REPOSITORY:
• RDM_BRANCH:
• RDM_MERGE:

• OSF_IMAGE:
• EMBER_IMAGE:
• CAS_IMAGE:
• MFR_IMAGE:
• MFR_REPOSITORY: miya-biz/RDM-modular-file-renderer
• MFR_BRANCH: feature/vuln-remediation-cos-wb
• UNOSERVER_IMAGE:

• WB_IMAGE:
• WB_REPOSITORY: miya-biz/RDM-waterbutler
• WB_BRANCH: feature/vuln-remediation
• EXCLUDE_NOTEBOOKS: