test(resolve-dependencies): demonstrate the ci-serialisation baseline reuse (item 4)

[sakanni]

Investigation of findings-register item 4, the ci-serialisation baseline. No production code changed and no fix designed — the deliverable is the demonstration. Item 4 is a correctness finding on a check under a standing gate, so the fix gets its own session.

Verdict: item 4 HOLDS, with the mechanism corrected

The register led with clone reuse. That is real but it is the lesser of two independent causes, and a fix addressing only it would not work.

(a) The already-cloned shortcut. Resolve-DependencyGraph.ps1:91 short-circuits before any ref resolution, so a dependency already present is never re-pointed.

(b) The resolver cannot be asked for the base branch. PR_BRANCH comes from github.event.pull_request.head.ref (resolve-dependencies/action.yml:132), which is constant for the whole job, and the action exposes no per-invocation override. The baseline leg is therefore structurally incapable of requesting the base branch. Deleting C:\bhom-deps between the legs would not fix item 4.

Each link, with evidence

Links 1 and 2 — observed on a real run. Sandbox run 28089097355 (XML_Toolkit) is the only run in sandbox history that traversed the baseline path end to end. It shows:

• 5 Cloning into lines on the branch leg, 0 on the baseline leg. Every dependency took the already-cloned path, not some of them.
• Assembly cache key depsasm-Windows-Release-354c6cb2... missed on the branch leg and hit on the baseline leg. That key is a SHA-256 over the sorted owner/repo@sha set (resolve-dependencies/action.yml:145-164), so an identical key proves identical resolved dependency SHAs across both legs, independently of what those SHAs happened to be. This is a stronger proof of the general claim than any single reproduction would be.
• The baseline leg's dependency build was skipped entirely; ProgramData was repopulated from the cache the branch leg saved.

What resets between legs. ci-serialisation:199 clears ProgramData\BHoM\Assemblies\*. resolve-dependencies' "Prepare folders" then removes that whole directory and Upgrades, and truncates deps/_shas.txt via New-Item -ItemType File -Force. Nothing anywhere touches C:\bhom-deps. No other cleanup exists in the action or either script.

Link 3 — demonstrated hermetically. The resolver honours PR_BRANCH on a fresh root when the dependency carries that branch, and falls back to the base branch when it does not. The capability exists; ci-serialisation simply never invokes it for the baseline.

Link 4, the one that matters — an explicit base-branch request on the second invocation is ignored while the clone is present. Both causes must be addressed.

BHoMBot comparison, sharpened. LoadDependencies(repo, branchName, defaultBranch) (CodeBuild_Engine/Compute/LoadDependencies.cs:11,31-32) clones if absent and then unconditionally calls CheckoutBranch(dep, branchName, defaultBranch) on every call, with the branch as an explicit argument. ResetBuiltRepos() clears the in-memory m_BuiltRepos memo so the per-leg re-checkout is not skipped as "already built this run". CI_Toolkit has neither half. CleanProgramDataFolder() deletes all of C:\ProgramData\BHoM, comparable to what resolve-dependencies already does.

The demonstration

.github/scripts/tests/Resolve-DependencyGraph.BaselineReuse.Tests.ps1, 6 Pester tests, all passing. Auto-discovered by lint-workflows.yml's existing powershell-tests job. Hermetic: a local bare repo reached via git insteadOf, no network and no BHoM install. Fixture is a fresh GUID temp dir per run and the job uses no caching action at all, so cold by construction.

Validated on a bare windows-latest runner: 6 new tests pass alongside the 18 existing ones.

Assertions describe current behaviour and are marked INVERTS-ON-ITEM4 where a fix would change them. Nothing presupposes an answer to Q2 through Q9.

Why not an end-to-end sandbox reproduction. It needs a subject repo whose dependencies.txt names a dependency in the same org plus a matching branch name on both. Every sandbox repo's dependencies.txt points at production BHoM/ or BuroHappoldEngineering/ repos, so the end-to-end case cannot be built without creating branches in production. What it would take: repoint a sandbox subject's dependencies.txt at the existing sandbox BHoM_Engine fork, override serialisation_engine_repo to the same fork to avoid Get-FolderName's repository-name collision guard, author a serialisation-affecting change on a matching branch in that fork, and open a sandbox PR. Happy to build that if you want the consequence shown as well as the mechanism.

Findings register

Register lives outside this repository; quoting the amendments.

Item 4 — HOLDS, mechanism corrected. Appended:

HOLDS, investigated 2026-08-24, with the mechanism corrected. There are TWO independent causes, and the clone reuse this entry led with is the lesser one. (a) The already-cloned path at :91 short-circuits before any ref resolution. (b) PR_BRANCH is sourced from github.event.pull_request.head.ref (resolve-dependencies/action.yml:132), constant for the whole job, with no per-invocation override, so the baseline leg cannot ask for the base branch and deleting C:\bhom-deps would not fix it. Evidence: sandbox run 28089097355 shows 5 clones on the branch leg and 0 on the baseline leg, with cache key depsasm-Windows-Release-354c6cb2... missing on the first and hitting on the second; that key is a hash over the resolved SHA set, so an identical key proves identical dependency SHAs across legs. Demonstrated by Resolve-DependencyGraph.BaselineReuse.Tests.ps1, whose load-bearing case shows an explicit base-branch request is ignored while the clone is present. BHoMBot comparison: LoadDependencies unconditionally re-checks-out every dependency with the branch as an explicit parameter, and ResetBuiltRepos() clears the memo that would otherwise skip it. CI_Toolkit lacks both.

Item 4a — new, context. Item 4 has effectively never fired.

Swept every serialisation run across seven sandbox repos: exactly one reached the baseline leg. All others skipped it (branch leg reported no error) or failed earlier. That one run was not a cross-repo pair, its PR branch existed on no dependency, so both legs resolved to develop and the baseline was correct by accident. Item 4 needs a branch-name collision between subject and dependency: common in production BHoM work, absent from sandbox history.

Item 4b — new, Low. ci-serialisation:199 is dead code.

Remove-Item "C:\ProgramData\BHoM\Assemblies\*" is redundant: two steps later resolve-dependencies' "Prepare folders" removes the whole directory and recreates it, and does the same for Upgrades, which :199 does not touch. Harmless, but it is the line a reader would take as the between-legs reset and it is not doing that job.

U2 — CLOSED. It works.

Sandbox run 28089097355: git checkout develop logged "Previous HEAD position was 77c5413 Merge into ", "Switched to a new branch develop", "branch develop set up to track origin/develop". actions/checkout leaves the remote-tracking ref in place for DWIM and the subject tree really is moved to the base branch. No silent failure or no-op.

U3 — CLOSED. It warns, it does not fail.

Same run logged "Failed to save: Unable to reserve cache with key depsasm-... , another job may be creating this cache." and the run concluded success. Item 29's racing-save concern is wasted work rather than job failure, and the missing continue-on-error on the assembly save is cosmetic.

[sakanni]

Superseded by #9, which cherry-picks this commit (9436840) and adds the fix, the ref reporting, and the no-op guard. Closing unmerged so the demonstration and the fix land together rather than as two commits that must be sequenced.

The register amendments quoted here (items 4a, 4b, U2, U3) are restated in #9's body.