Tracking: removing the .gitmodules `branch` pin silently disabled testbed version updates across SDK repos

Over the last few months the branch = vX.Y.Z property was dropped from the test-harness / flagd-testbed submodules in four SDK repos. It looks like a harmless cleanup — the submodule still pins an exact SHA either way — but that one line is what Renovate uses to track the testbed, and without it testbed updates in those repos have stopped happening entirely.

Filing here because the impact is on testbed adoption across the ecosystem rather than on any single SDK.

What the property actually did

Renovate's git-submodules manager reads branch from .gitmodules as the dependency's current version. With branch = v3.5.0 present it resolves the submodule against this repo's release tags and opens a normal version bump, rewriting both the pointer and the pin:

 [submodule "providers/flagd/test-harness"]
 	path = providers/flagd/test-harness
 	url = https://github.com/open-feature/test-harness.git
-	branch = v2.10.1
+	branch = v2.10.2

Those arrived as chore(deps): update dependency providers/flagd/test-harness to v2.10.2 on branches like renovate/providers-flagd-test-harness-2.x. They were auto-created (the shared open-feature/community-tooling preset exempts https://github.com/open-feature/** from dashboard approval) and auto-merged (matchManagers: ["git-submodules"] → automerge: true). Nobody had to do anything — which is exactly why nobody noticed when it stopped.

Where it was removed

repo	removed in	pin at the time
js-sdk-contrib	open-feature/js-sdk-contrib#1461 — feat!: graceful fallback to code default	v2.10.2
python-sdk-contrib	open-feature/python-sdk-contrib#347 — feat!: graceful fallback to code default	v2.11.1
java-sdk-contrib	open-feature/java-sdk-contrib#1778 — fix: various custom operator conformance fixes	v3.5.0 (both submodules)
python-sdk-contrib	open-feature/python-sdk-contrib#386 — fix: various custom operator conformance fixes	v3.5.0, re-added in open-feature/python-sdk-contrib#377 only 8 days earlier
go-sdk-contrib	open-feature/go-sdk-contrib#874 — fix: core lib update for various custom operator conformance fixes	v2.11.1

Two cross-repo porting waves, and the deletion travelled with the change each time. Nothing in the diffs suggests it was deliberate — most likely the pin fought a bump to an unreleased testbed commit, and dropping it was the quickest way past that.

What broke

Renovate degrades to digest updates. With no branch, there is no version to compare against, so it falls back to chasing the tip of the testbed default branch. The dependency dashboards show it plainly — note Updates: undefined:

## Pending Approval
- [ ] chore(deps): update providers/flagd/flagd-testbed digest to b308c1b

## Detected Dependencies
git-submodules (1)
 - providers/flagd/flagd-testbed 7575a1d... → [Updates: undefined]

And those digest updates never become PRs. The preset's auto-create exemption is keyed on matchSourceUrls, which no longer matches once the dependency stops resolving, so the global dependencyDashboardApproval: true takes over and parks them behind a checkbox that nobody ticks. They are sitting unactioned right now in open-feature/java-sdk-contrib#143, open-feature/go-sdk-contrib#53 and open-feature/python-sdk-contrib#126.

The net result is zero automated testbed updates since the removal. Before, java's .gitmodules history is a wall of ~15 renovate bumps. After, across all four repos: none. Every testbed move since has been a human dragging it along inside an unrelated feature PR — open-feature/java-sdk-contrib#1817 is literally titled chore(flagd): bump test-harness submodules to v3.8.0.

And the pins have drifted apart. java-sdk-contrib has two submodules pointing at this repo which used to be bumped in lockstep:

• providers/flagd/test-harness → b308c1b (v3.10.1)
• tools/flagd-api-testkit/test-harness → 7575a1d (v3.8.0)

Two versions of the same conformance suite in one build, silently, because nothing was watching.

The fix

Each sub-issue below has a PR attached that restores branch = <tag> on the testbed submodule, set to the tag that repo currently points at.

That is the whole fix. No Renovate config change is needed: the preset's existing https://github.com/open-feature/** exemption starts matching again as soon as the dependency resolves to a version, so version PRs resume on their own. And with a pin in place the digest-update path is never taken, so there is nothing extra to suppress.

The pins are set to each submodule's current tag, so none of the PRs move a submodule or change behaviour on their own. The next testbed release is what arrives as a normal Renovate version PR.

Not covered by the sub-issues

• php-, ruby- and rust-sdk-contrib never had the pin at all, and they don't extend community-tooling — they sit on config:base / config:recommended, neither of which enables the git-submodules manager. Their testbed submodule is invisible to Renovate, so a pin alone won't help; the manager has to be switched on first. dotnet-sdk-contrib extends the preset but has likewise never had a pin. Worth a follow-up if we want testbed updates to reach every SDK.
• The schemas submodule in python-sdk-contrib lost branch = protobuf-v0.6.1 in the same PR (open-feature/python-sdk-contrib#347). Across all four repos it is the only non-testbed submodule that lost a pin while still in use — every other live submodule (spec, schemas, flagd-schemas, wasm-releases) never had one. It is now folded into open-feature/python-sdk-contrib#422, with the caveat that it needs a decision rather than a revert: the submodule has moved onto the json/json-schema-* tag series, so the restored pin follows that rather than the protobuf-* series it originally tracked.
• The preset automerges submodule updates unattended (matchManagers: ["git-submodules"] → automerge: true). Restoring the pins re-enables that, and it now includes majors like v2→v3 that reshape the gherkin. If we'd rather have those reviewed, { "matchManagers": ["git-submodules"], "matchUpdateTypes": ["major"], "automerge": false } in community-tooling would do it. Flagging rather than deciding — it is independent of these PRs.

Start by comparing the .gitmodules files and recent history in js-sdk-contrib, python-sdk-contrib, java-sdk-contrib, and go-sdk-contrib, then review Renovate's git-submodules behavior and the listed pending digest updates. Done means restoring branch = for each affected testbed submodule at its current tag, without changing the submodule pointer, so version updates resolve and resume normally.