DependabotによるPull Requestに対しての対応を検討したい。

[daisukenishino2]

Dependabotの機能（PR作成機能）には

• 「バージョン更新（Version updates）」と
• 「セキュリティアップデート（Security updates）」

の2種類がある。

「セキュリティアップデートも含めて、特定のブランチ（例: develop）にPRを集約したい」場合は、
GitHub ActionsでPR作成時にベースブランチを自動変更するワークフローを組む方法が一般的とのこと。

name: Change Dependabot PR Base Branch

on:
  pull_request_target:
    types: [opened]

jobs:
  change-base:
    if: github.actor == 'dependabot[bot]'
    runs-on: ubuntu-latest
    steps:
      - name: Change base branch
        run: |
          gh pr edit ${{ github.event.pull_request.number }} --base develop
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          

また、ブランチにPRをマージ後、テストし、その結果を得たい。

以前作成した、CIスクリプトを「windows-latest」で実行できないか？

[OsscJpDevInfra]

調査結果と対応

1. ベース ブランチの集約について

現状を確認したところ、既定ブランチが develop でした（PR #510 の base も develop）。
Dependabot のセキュリティ アップデートは既定ブランチにしか PR を出さないため、
「master に出てしまう」状態にはなっていません。

ただし本 Issue の方針は develop の手前に受けブランチを挟むことなので、
振り替えのワークフローは必要です。

.github/dependabot.yml の target-branch: では代替できません。
target-branch が効くのはバージョン更新だけで、セキュリティ アップデートには効かないためです。
記載いただいた gh pr edit --base の方法が、実質唯一の手段になります。

2. 想定するフロー

Dependabot が PR を作成（base: develop）
      │
      │ ① dependabot-retarget.yml が base を deps へ書き換え
      ▼
 PR（base: deps）
      │ ② 人がマージ
      ▼
   deps ─── ③ build-windows.yml が windows-latest でビルド
      │ ④ 結果が OK なら、人が PR を作って develop へマージ
      ▼
  develop

①③がワークフロー、②④が人の作業です（AGENTS.md の線引きに合わせています）。

---

追加したもの

ファイル	内容
.github/workflows/dependabot-retarget.yml	Dependabot の PR の base を deps へ振り替える
.github/workflows/build-windows.yml	deps への push で 1_BuildAll.ps1 を windows-latest 実行

retarget 側で、ご提示の YAML に足した点

追加	理由
permissions: pull-requests: write	Dependabot のイベントでは GITHUB_TOKEN が既定 read-only。無いと base を書き換えられない
base.ref == 'develop' の判定	すでに deps 宛のものを再度書き換えないため
値を env: 経由で run: へ渡す	${{ }} の直書きはシェルに解釈される余地が残るため

checkout は行っていません。pull_request_target は書き込み権限付きでベース ブランチ側の定義を
動かすため、PR のコードを実行すると、そこに任意のコードを書ける相手へ権限を渡すことになります。

---

CI 化にあたって直した箇所

CI では通らない箇所が 2 つあったため、併せて修正しました。

① ClickOnce の署名エラー（MSB3482）

WSClientWinCone_sample.csproj は署名証明書を拇印で直接指定しており、同梱の .pfx は
パスワード保護のため、実行のたびに作り直される CI では再現できません。

判定ロジックをワークフロー側に書くと二重管理になるので、1_BuildAll.ps1 に
-IgnoreErrors <正規表現…> を追加しました。除外したものは握り潰さず、件数と内容を残します。

  OK  エラー 0 / 警告 0 / 既知 1  (8.7 秒)

======== 既知として除外したエラー ========
  除外条件 : MSB3482
  [WSClnt_sample (net48)] ... error MSB3482: 署名中にエラーが発生しました: ...

リリース判定では使わない旨を RELEASE.md に明記しています（目視で 1 件だけであることを
確かめるのが本筋で、この引数は人が見ない CI のためのものです）。

② VisualStudioVersion の固定値

z_Common.bat が set VisualStudioVersion=18.0 と固定していました。
Web アプリの csproj はこの値で targets のパスを組み立てます。

<VSToolsPath>$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" />

GitHub の windows-latest は VS 2022（17.x）のため、18.0 を渡すと v18.0\WebApplications\ を
探して MSB4226 になります（BUILDING.md 5 節と同じ現象）。
MSBuild を解決したのと同じ vswhere からバージョンを求めるようにしました。

VS 18 のある環境では従来どおり 18.0 になるため、ローカルの挙動は変わりません
（Web アプリの再ビルドで確認済み）。

---

CI に載せたのはビルドだけです

スクリプト	CI	理由
1_BuildAll.ps1	○	DB を必要としない
2_RunAllTests.ps1	—	6 件中 2 件（SimpleBatch）が Northwind を使う
3_SmokeTest.ps1	—	18 件のほぼ全てが Northwind を使う

GitHub の Windows イメージに SQL Server がありません（LocalDB と sqlcmd のみ）。
サンプルの接続文字列は Data Source=localhost; User ID=sa で、LocalDB
（(localdb)\MSSQLLocalDB・Windows 認証）では代用できません。
Docker は入っていますが Windows コンテナのみで、Linux の SQL Server イメージは動きません。
Northwind の作成スクリプトもリポジトリにありません（CREATE ORDERS2.sql だけ）。

これらを解消すれば 2・3 も載せられます。

イメージ側の充足状況（windows-2025 で確認）

必要なもの	イメージ
MSBuild	Visual Studio 2022 Enterprise 17.14
.NET Framework 4.8 の参照アセンブリ	あり（4.8 / 4.8.1）
.NET 10 SDK	あり（10.0.302 ほか）
IIS Express	あり
nuget.exe	リポジトリに同梱（root/programs/nuget.exe）
SQL Server	無し

z_Common.bat は vswhere で MSBuild を解決するため、エディションが Enterprise でも通ります。

---

検証したこと

項目	結果
1_BuildAll.ps1 の構文（PowerShell 5.1 / 7）	両方 OK、BOM 保持
-IgnoreErrors 無しで実行	NG / 終了コード 1
-IgnoreErrors "MSB3482" で実行	OK / 終了コード 0、除外 1 件を一覧表示
同上を PowerShell 5.1 で実行	同じ結果
z_Common.bat の解決値	VisualStudioVersion 18.0（変更前と同一）
Web アプリの再ビルド	OK、エラー 0
ワークフロー YAML	2 本ともパース成功、job / step 構造を確認

---

動かすために必要な作業

1. deps ブランチを作る（現存しません）。gh pr edit --base は既存ブランチしか指せません
2. dependabot-retarget.yml を develop にマージする。pull_request_target はベース
   ブランチ側の定義で動くため、既定ブランチに無いと発火しません
3. build-windows.yml は deps 上にあれば動きます

運用として、④の後に deps を develop へ追従させる必要があります。
古いままだと、次の PR の差分に無関係な変更が混ざります。

未検証のリスク

base を書き換えた PR に Dependabot がどう反応するかは、実際に流すまで確認できません。
更新の再作成時に PR を作り直す挙動が報告されており、その際 base が develop に戻る可能性が
あります。最初の 1 件で実挙動を確認するのが確実です。

---

変更はワーキング ツリーに置いてあります（コミットはしていません）。

?? .github/workflows/dependabot-retarget.yml   新規
?? .github/workflows/build-windows.yml         新規
 M root/programs/1_BuildAll.ps1                 -IgnoreErrors の追加
 M root/programs/CS/z_Common.bat                VisualStudioVersion を vswhere から導出
 M root/programs/BUILDING.md                    9 節「GitHub Actions で回す」を新設
 M root/programs/RELEASE.md                     -IgnoreErrors をリリース判定で使わない旨

[OsscJpDevInfra]

単体テストまで CI に載りました

https://github.com/OpenTouryoProject/OpenTouryo/actions/runs/30979772579

全ステップ成功しています。

ステップ	所要
Build all（31 ステップ）	5 分 36 秒
Install SQL Server	4 分 49 秒
Set up Northwind	16 秒
Set up C:\root and locale	4 秒
Run all tests（6 件）	43 秒
合計	約 12 分

---

前回コメントの訂正

先のコメントに、その後の調査で誤りと分かった記述があります。訂正します。

1.「Northwind の作成スクリプトもリポジトリにありません」→ 誤り

LocalServicesOnDocker に sqlserver/init/instnwnd.sql（Microsoft 公式の Northwind DDL、
約 1 MB）があります。これが最後の欠落でした。ご教示ありがとうございました。

2.「CI に載せたのはビルドだけです」→ 更新

2_RunAllTests.ps1（6 件）も載りました。DB を必要とする 2 件（SimpleBatch）も含みます。

3.「windows-latest は VS 2022 Enterprise 17.14」→ 誤り

イメージの README にそう書かれていましたが、実際は Visual Studio 18 Enterprise でした。

BUILDFILEPATH "C:\Program Files\Microsoft Visual Studio\18\Enterprise\MSBuild\Current\Bin\MSBuild.exe"

このため、VisualStudioVersion の固定値（18.0）が偶然一致しており、
予想した MSB4226 は起きていませんでした。 vswhere から導出する変更自体は、
一致が偶然である以上は妥当と考えて残しています。

---

SQL Server の用意

LocalServicesOnDocker の docker-compose.yml はそのままでは使えませんでした。
sqlserver サービスが Linux イメージ（mcr.microsoft.com/mssql/server）で、
windows-latest は Linux コンテナを動かせないためです
（Hyper-V による VM が要るが、runner 自体が入れ子の VM のため多段にできない）。

そこで runner へ直接 SQL Server を入れ、instnwnd.sql だけを借りる構成にしました。

要素	入手先
SQL Server 2022	ankane/setup-sqlserver（コミットで固定。v1 はタグではなくブランチ）
instnwnd.sql	LocalServicesOnDocker（コミットで固定）
CREATE ORDERS2.sql	本リポジトリに同梱

初期化で押さえた点は 3 つです。

1. sa のパスワードを構成ファイルに合わせる（seigi@123）
   構成側を CI 用に書き換えると「実際に使われる設定」と乖離するため、DB を構成に合わせました
2. 照合順序を Japanese_CI_AS にする（docker-compose.yml の MSSQL_COLLATION と同じ）
   CREATE DATABASE ... COLLATE で与えます。Northwind の列は COLLATE 句を持たないため継承します
3. Shippers が 3 行あることでロード完了を判定し、不完全なら作り直す（最大 3 回）
   判定方法は start-up.sh に合わせました

instnwnd.sql は DB を作らない（対象 DB の中で実行する）ので、先に CREATE DATABASE が要ります。

---

DB 以外に、2 つ前提が要りました

初回は 6 件すべて NG でした。切り分けた結果、DB とは別に 2 つ不足していました。

① C:\root が要る

構成ファイルが絶対パスを直書きしています。

ファイル	キー
TestCode/App.config	FxXMLMSGDefinition / FxXMLSPDefinition
TestBatch/SimpleBatch/app.config	SqlTextFilePath

無いと GetMessage は例外を出さずに空を返し、SimpleBatch は
resource file [...] was not found で落ちます。

実体はリポジトリ内（root/files）にあるので、ジャンクションで繋ぎました（コピーしない）。

② 日本語環境が要る（「書式」と「言語」は別軸）

軸	何が変わるか	runner で直せるか
CurrentCulture	日付・数値の書式	直せる（Set-Culture ja-JP）
CurrentUICulture	メッセージの言語	直せない

書式の方は、CompareResult.ps1 の <DATE> が \d{4}/\d{1,2}/\d{1,2} で、
4/24/1977（en-US）が素通りしていました。Set-Culture で解消しました。

言語の方は手段がありませんでした。

試したこと	結果
Install-Language -Language ja-JP	ハング。 Windows Update 経由で取得しようとして応答が返らず、16 分以上停止
Set-WinUILanguageOverride	言語パックの導入が前提のため使えない
PreferredUILanguages を直接書く	無視された。 Windows は未インストールの言語を候補から外す

ワークフローの出力で確定しています。

新しいプロセスの Culture / UICulture : ja-JP / en-US

そこで、言語に依存する 2 か所を別々に処理しました。

1. GetMessage は設定で固定

GetMessage はカルチャでファイルを選び分けています
（MSGDefinition.xml → MSGDefinition_ja.xml）。en-US では既定の英語版に落ちます。

TestCode の App.config と appsettings.json に、フレームワークが元から持つキーを指定しました。

<add key="FxBusinessMessageCulture" value="ja-JP" />

ja-JP → ja のフォールバックで MSGDefinition_ja.xml に解決されるため、
ローカルで起きている経路と同じです。ローカルで実行して、結果が変わらないことを確認しました。

これは CI のための小細工ではなく、テストの決定性の問題と考えています。
固定しないと、どのマシンで動かすかで結果が変わります。

2. OS のメッセージは正規化

暗号系の例外文字列（Key does not exist. / キーがありません。）は Windows が返すため、
設定では固定できません。CompareResult.ps1 に規則を足し、文言だけを <OSMSG> に潰しました。

行ごと落としていません。 例外が起きたこと自体は「行の存在」で分かるため、
行を残せば、例外が起きなくなったときに差分として検知できます。

---

ClickOnce の署名エラーは、ローカルと CI でコードが違いました

前回 -IgnoreErrors "MSB3482" としましたが、CI で出たのは別のコードでした。

環境	コード	失敗地点
ローカル	MSB3482	マニフェストの署名。.pfx が既にキー コンテナにあるため最後まで進む
CI	MSB3325 ＋ MSB3321	ResolveKeySource のキー取り込み。署名に到達しない

3 つをまとめ、さらに当該プロジェクトに限定しました。

-IgnoreErrors 'error MSB(3482|3325|3321):.*WSClientWinCone_sample\.csproj'

コードだけで除外すると、同じコードが他プロジェクトで出たときに見逃すためです。

---

対象外（現時点）

対象	理由
3_SmokeTest.ps1（18 件）	IIS Express・aspnet_state・Oracle / MySQL / PostgreSQL が要る
GUI アプリケーション	RELEASE.md 4 節の手作業のまま
SQL Server 以外の DBMS への接続	自動テストは /Dap SQL のみを使う （TestSQLUtility は 4 DBMS の SQL 生成を検証するが、接続はしない）

---

残件

Dependabot の PR に対する retarget の実挙動が、まだ確認できていません。

pull_request_target の発火と、非 Dependabot の PR を除外する条件式は実証済みです
（PR #519 を開いたときにワークフローが起動し、skipped で終わっています）。
ただし gh pr edit --base deps が実際に走った実績はありません。

PR #510 はワークフロー導入前に作られたもので、opened にしか反応しないため対象外です。
次のセキュリティ アップデートで検証されます。

---

変更したファイル

.github/workflows/build-windows.yml            ビルド＋単体テスト
.github/workflows/dependabot-retarget.yml      base を deps へ振り替え
root/programs/1_BuildAll.ps1                   -IgnoreErrors を追加
root/programs/CompareResult.ps1                OS メッセージの正規化を追加
root/programs/CS/z_Common.bat                  VisualStudioVersion を vswhere から導出
root/programs/CS/Frameworks/Tests/TestCode/App.config        FxBusinessMessageCulture
root/programs/CS/Frameworks/Tests/TestCode/appsettings.json  同上
root/programs/BUILDING.md                      9 節「GitHub Actions で回す」
root/programs/TESTING.md                       CI への導線
root/programs/RELEASE.md                       -IgnoreErrors をリリース判定で使わない旨

切り分けの経緯（どの実行で差分が 18 → 4 → 0 になったか）と、
試して駄目だった手段は BUILDING.md 9 節に残しました。