open-feature / open-feature/python-sdk-contrib

Restore the .gitmodules branch pins so Renovate tracks flagd submodule versions again

Ouverte Adaptée aux débutants
#421 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Langage dominant
Python
Étoiles
27
Forks
33
Merge moyen
5 h 7 min
PR mergées (30 j)
9

Description

The branch pin on providers/openfeature-provider-flagd/openfeature/test-harness has been removed from .gitmodules twice: first in open-feature/python-sdk-contrib#347 (at v2.11.1), restored in open-feature/python-sdk-contrib#377, then removed again 8 days later in open-feature/python-sdk-contrib#386 (at v3.5.0). It reads as harmless — the exact SHA is still pinned — but it is the line Renovate uses to track testbed versions, and testbed updates here have been dead ever since.

The submodule sits at 7575a1d (v3.8.0) while the testbed has released v3.10.1. Exactly one manual bump has landed since, and a digest update is parked unactioned on the dependency dashboard in open-feature/python-sdk-contrib#126.

The PR restores the pin at v3.8.0, the tag it points at today.

open-feature/python-sdk-contrib#347 also dropped branch = protobuf-v0.6.1 from the schemas submodule, never restored. Across all four affected repos this is the only non-testbed submodule that lost a pin while still in use, so the PR covers it too.

That one needs a decision rather than a revert: schemas has since moved to 1daf5ff, tagged json/json-schema-v0.2.15 — a different tag series from the protobuf-* one it used to track. The PR pins it to the series it is actually on; flag it if tracking protobuf-* was deliberate.

Why this matters

Renovate's git-submodules manager reads branch from .gitmodules as the dependency's current version. With the pin present it resolves against the testbed's release tags and opens an ordinary version bump, rewriting the pin itself:

-	branch = v2.10.1
+	branch = v2.10.2

Without it there is no version to compare against, so Renovate falls back to chasing the tip of the testbed default branch — a digest update. Those don't match the community-tooling preset's matchSourceUrls auto-create exemption, so they get parked behind a dashboard checkbox instead of becoming PRs. Net effect: no automated testbed updates in this repo since the removal.

The fix

The attached PR restores branch = <tag> on the testbed submodule, set to the tag it currently points at. That is the whole fix — no Renovate config change is needed, because the preset's existing exemption starts matching again as soon as the dependency resolves to a version.

Parent: open-feature/flagd-testbed#398

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Commencez par examiner les entrées des sous-modules concernés dans .gitmodules, en particulier providers/openfeature-provider-flagd/openfeature/test-harness et schemas, et comparez leurs commits actuels aux tags indiqués. La tâche est terminée lorsque le pin de la branche testbed est restauré à v3.8.0 et que la série de tags appropriée de schemas est sélectionnée, le choix de protobuf-v0.6.1 étant confirmé ou signalé pour examen.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
git
Domaine
tooling
Type d'issue
Bug
Difficulté
2/5
Temps estimé
1-3 heures
Activité
Active
Clarté
Plutôt claire
Accessibilité débutants
76/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.