You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Keeping metadata.json dependencies current across ~90 modules is manual and stale-prone, and the existing tooling has aged out:
dist/puppetsync/tasks/modernize_metadata_json.rb is static: hardcoded version requirements (puppetlabs/stdlib '>= 8.0.0 < 10.0.0', puppet/systemd '>= 4.0.2 < 7.0.0'), one-off rename rules (herculesteam→puppet, trlinkin→puppet), and a static data/version_requirements.json lookup table. Every new release cycle means editing the task.
Its bump_version helper also hardcodes a specific author line and an iptables-specific changelog comment — leftovers from the last session it was used for.
There is a working dynamic prototype outside the repo (update-metadata): for each dependency it queries the Forge API (/v3/modules/<slug>), follows superseded_by chains to rename moved/deprecated modules, checks whether the current release satisfies the existing version_requirement, and if not bumps the upper bound to < next major (keeping the lower bound; skipping requirements that aren't a clean two-bound range). That logic is right — but it does per-process lookups, which multiplied across ~90 repos would hammer the Forge API with mostly-duplicate requests.
Proposed design
A new pipeline task (replacing the static parts of modernize_metadata_json) with a single pass of version lookups shared across all repos:
Collect: scan every repo's metadata.json (dependencies + simp.optional_dependencies) and build the set of unique module slugs. Across the whole org this is a few dozen unique modules, not hundreds of requests.
Resolve once: one Forge API request per unique slug, following superseded_by chains (chain hops also cached), producing a resolution table: slug → {current_slug, current_version, deprecated?}.
Apply per repo: rewrite each repo's dependencies from the table — rename superseded modules, bump the upper bound to < nextmajor(current_version) when the current release falls outside the existing range, leave in-range requirements untouched, and warn-and-skip anything that isn't a two-bound range.
Implementation notes:
The simplest way to get the shared cache is to make this a single task invocation over all repo paths (the pattern checkout_git_feature_branch_in_each_repo already uses), rather than one task process per repo. Alternatively a pre-stage fetches the table once and passes it as a task parameter.
Version bump + changelog entry generation should be parameterized (message/author from the session config), not hardcoded like the current bump_version.
JSON needs no comment preservation, so this is JSON.parse + pretty_generate like the other metadata tooling.
Retire data/version_requirements.json and the hardcoded transform rules once this lands.
Relationship to other work
Renovate: Renovate manages pinned dependencies well, but metadata.json carries version ranges with semantics Renovate doesn't handle for us today (supersede-following, bump-upper-bound-only). This task keeps range maintenance in puppetsync, consistent with the Renovate/puppetsync division of labor (versions vs. structure) — if Renovate's puppet datasource ever covers this properly, we can hand it over.
Problem
Keeping
metadata.jsondependencies current across ~90 modules is manual and stale-prone, and the existing tooling has aged out:dist/puppetsync/tasks/modernize_metadata_json.rbis static: hardcoded version requirements (puppetlabs/stdlib '>= 8.0.0 < 10.0.0',puppet/systemd '>= 4.0.2 < 7.0.0'), one-off rename rules (herculesteam→puppet, trlinkin→puppet), and a staticdata/version_requirements.jsonlookup table. Every new release cycle means editing the task.bump_versionhelper also hardcodes a specific author line and an iptables-specific changelog comment — leftovers from the last session it was used for.There is a working dynamic prototype outside the repo (
update-metadata): for each dependency it queries the Forge API (/v3/modules/<slug>), followssuperseded_bychains to rename moved/deprecated modules, checks whether the current release satisfies the existingversion_requirement, and if not bumps the upper bound to< next major(keeping the lower bound; skipping requirements that aren't a clean two-bound range). That logic is right — but it does per-process lookups, which multiplied across ~90 repos would hammer the Forge API with mostly-duplicate requests.Proposed design
A new pipeline task (replacing the static parts of
modernize_metadata_json) with a single pass of version lookups shared across all repos:metadata.json(dependencies+simp.optional_dependencies) and build the set of unique module slugs. Across the whole org this is a few dozen unique modules, not hundreds of requests.superseded_bychains (chain hops also cached), producing a resolution table:slug → {current_slug, current_version, deprecated?}.< nextmajor(current_version)when the current release falls outside the existing range, leave in-range requirements untouched, and warn-and-skip anything that isn't a two-bound range.Implementation notes:
checkout_git_feature_branch_in_each_repoalready uses), rather than one task process per repo. Alternatively a pre-stage fetches the table once and passes it as a task parameter.bump_version.JSON.parse+pretty_generatelike the other metadata tooling.data/version_requirements.jsonand the hardcoded transform rules once this lands.Relationship to other work
metadata.jsoncarries version ranges with semantics Renovate doesn't handle for us today (supersede-following, bump-upper-bound-only). This task keeps range maintenance in puppetsync, consistent with the Renovate/puppetsync division of labor (versions vs. structure) — if Renovate'spuppetdatasource ever covers this properly, we can hand it over.