Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe ChangesSubmodule version tracking
Priority: ➖ Normal Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Other · Severity of issue fixed: Medium Suggested reviewers: Merge Risk: ⚪ Minimal · up to The submodule pin updates match the stated tracking intent, with no identified production or build risk. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
89ba877 to
a2cb5d5
Compare
Renovate's git-submodules manager reads `branch` from .gitmodules as the dependency's current version. Without it there is no version to compare against, so Renovate falls back to chasing the tip of the submodule's default branch as a digest update -- which does not match the community-tooling auto-create exemption and ends up parked on the dependency dashboard. The result has been no automated updates in this repo since the pin was dropped. Restore the pin at the tag each submodule currently points at, so the next release arrives as an ordinary Renovate version PR again. Also add a header comment to .gitmodules explaining what the `branch` lines are for. The pin has now been deleted as drive-by cleanup several times across the SDK repos, in each case silently switching off updates, so it is worth saying out loud in the file itself. Note that schemas has moved from the protobuf-* tag series it used to track onto json/json-schema-*, so its pin follows the series it is actually on. Signed-off-by: Simon Schrottner <simon.schrottner@flagsmith.com>
769a138 to
a4603c2
Compare
) Part of open-feature#125. ## This PR - stops Renovate producing `digest` updates for submodules - automerges submodule `minor` and `patch`, sends `major` to a PR for review - keeps `minimumReleaseAge: null`, now as its own rule with the reason stated - teaches Renovate to read prefixed refs as versions, so `flagd-schemas` and `wasm-releases` can be pinned at all ## Why Renovate's [`git-submodules`](https://docs.renovatebot.com/modules/manager/git-submodules/#updating-to-specific-tag-values) manager decides everything from one line in `.gitmodules` — the docs describe setting a tag as `branch`, and [`extract.ts`](https://github.com/renovatebot/renovate/blob/main/lib/modules/manager/git-submodules/extract.ts) shows why: with a semver `branch = v3.10.1` it produces real version updates and rewrites both the pin and the gitlink; without one, `currentValue` is undefined and all it can compute is a digest against the upstream default branch. Since open-feature#124 removed the dashboard gate, that path is opening PRs. Five SDKs are being offered `spec` main (`d0aa675`), six commits past `v0.9.0` — nothing in the queue corresponds to a release. A digest update also carries no version information, so no automerge policy can be applied to it safely. ## Prefixed refs Turning the digest path off is only safe if what we care about can be pinned, and two upstreams could not be: - **`flagd-schemas`** releases via release-please components, so its tags are `json/json-schema-vX.Y.Z` and `protobuf-vX.Y.Z`. Neither parses as semver, so a pin written that way silently does nothing — open-feature/python-sdk-contrib#422 already carries one that is inert until this lands. - **`wasm-releases`** has no tags, but publishes each version as a `publish-wasm-evaluation-vX.Y.Z` branch. The [`git-refs`](https://docs.renovatebot.com/modules/datasource/#git-refs) datasource pools heads and tags, so a branch serves as a version. One [`regex` versioning](https://docs.renovatebot.com/modules/versioning/#regular-expression-versioning) rule covers both. The prefix is captured as `compatibility`, which the docs define as: *"A proposed Renovate update will never change the specified compatibility value."* So each prefix stays its own series and one is never offered as an upgrade to another — which matters because both `flagd-schemas` series live in the same repo. Enforced in [`lookup`](https://github.com/renovatebot/renovate/blob/main/lib/workers/repository/process/lookup/index.ts#L403), which filters candidates through `isCompatible`. It is selected by [`matchCurrentValue`](https://docs.renovatebot.com/configuration-options/#matchcurrentvalue) rather than `matchSourceUrls`, because a source URL cannot tell the two series apart and the pin can. Requiring the prefix to end in `-` or `/` leaves bare `vX.Y.Z` pins on their native semver path. Two constraints from the docs that this satisfies: `major`/`minor`/`patch` capture groups must be purely numeric — the `v` and the prefix sit outside them — and [`extractVersion`](https://docs.renovatebot.com/configuration-options/#extractversion) would be the wrong tool, since `getNewValue` returns the version verbatim, so stripping the prefix would write `branch = v0.2.16`, a ref that does not exist. Checked against all 234 refs on the four upstreams: each pin resolves to its own series with no cross-series leak, `v3.10.1` and `v0.9.0` are correctly skipped, and rust-sdk-contrib's stale `json/json-schema-v0.2.13` is correctly offered `v0.2.14` and `v0.2.15`. ## Notes `minimumReleaseAge` has to stay `null`: `git-refs` exposes no release timestamps, so any cooldown blocks submodule updates forever. So automerging minor and patch means a tagged release can merge with no waiting period — how it behaved before the pins were dropped, but a deliberate choice now rather than an inherited one. All these upstreams are also pre-1.0, so `0.2.15 → 0.3.0` counts as a minor. The `wasm-releases` pins point at branches. If go-feature-flag prunes old `publish-wasm-evaluation-v*` branches, Renovate loses `currentValue` and quietly stops tracking. The gitlink stays valid, so nothing breaks — but nothing updates either. ## Ordering These rules only act once a submodule carries a `branch` pin, and repos without one stop getting updates when this merges. That is the intent for everything being pinned in open-feature#125, where 13 no-op pins are now open across 8 repos. The one case it cannot help is `openfeature.dev`'s `external-content/community`: the upstream has no versioned refs at all. Validated with `renovate-config-validator`. --------- Signed-off-by: Simon Schrottner <simon.schrottner@flagsmith.com>
Closes #421
Parent: open-feature/flagd-testbed#398
Restores the
branchpins that were dropped from.gitmodules.Why
Renovate's
git-submodulesmanager readsbranchfrom.gitmodulesas the dependency's current version. With the pin present it resolves against the submodule's release tags and opens an ordinary version bump, rewriting the pin itself:Without it there is no version to compare against, so Renovate chases the tip of the submodule's default branch instead — a digest update. Those don't match the
community-toolingpreset'smatchSourceUrlsauto-create exemption, so they get parked behind a dashboard checkbox rather than becoming PRs. Net effect: no automated testbed or schemas updates in this repo since the pins were removed.What this does
Restores
branch = v3.8.0onproviders/openfeature-provider-flagd/openfeature/test-harness.Restores a pin on
providers/openfeature-provider-flagd/openfeature/schemas, which lostbranch = protobuf-v0.6.1in the same PR (feat!: graceful fallback to code default when no default variant #347) and was never restored.This one is not a straight revert and is worth a look. The submodule has since moved to
1daf5ff, which is taggedjson/json-schema-v0.2.15— a different tag series from theprotobuf-*one it used to track. The pin here follows the series the submodule is actually on, so Renovate will proposejson/json-schema-*updates going forward. If trackingprotobuf-*was deliberate, say so and I'll change it.Both pins are set to the tag each submodule points at today, so this commit changes no behaviour on its own — it does not move any submodule. The next release then arrives as a normal Renovate version PR.