Widen the naming-fork replacement to vertical modules (FENG-2988)

[Martin Charbonneau (mcharbo)]

Jira issue link: FENG-2988

What

Widens the naming-fork replacement rule in renovate-terraform.json to cover
workleap/terraform-*-vertical-*, completing the wave that #211 started for
terraform-*-enterprise-*.

One-line change: matchRepositories is dropped rather than extended.

Why drop the key instead of listing both patterns

The config's autodiscoverFilter is already exactly
["workleap/terraform-*-enterprise-*", "workleap/terraform-*-vertical-*"]. Now that the rule
should apply to both, a matchRepositories listing those same two patterns would be pure
duplication that can silently drift from the filter above it. Removing it makes the rule
follow whatever the config discovers.

Happy to list both patterns explicitly instead if reviewers prefer the rule to be
self-describing — say the word.

Why this is safe

Unchanged from #211 and re-verified there against the real estate:

• matchCurrentValue stays /^0\.4\.[23]$/. The fork is cut from upstream 0.4.3
  (a837381), and upstream 0.4.2 -> 0.4.3 is purely additive (1,611 insertions, 0
  deletions), so neither pin changes a generated name.
• The fork's main does not contain 80c13e5 "Enable use of hyphen for API Management
  resources", so the APIM rename footgun stays avoided.
• replacementVersion is 1.0.1, the opt-in unique-random-string build.

Review gate

terraform plan on each downstream PR must show random_string destroys only - 0 creates, 0
replacements, and no moved blocks (the module "azure_naming" block name is unchanged, so
the address is unchanged). Read that as "no azurerm_* create or replace", not "no azurerm_*
lines" - the FENG-2646 pilot confirmed pre-existing drift muddies the diff. Any other destroy is
a stop signal.

Per repo before merge: grep -rn "name_unique\|unique-seed" must be clean.

Fan-out

PR runs are dry by construction since #211, so opening this does not touch the estate - the
renovate-terraform-enterprise check here will log what it would do and create nothing. Fan out
deliberately after merge via workflow_dispatch on Renovate Terraform Enterprise, or let the
nightly cron pick it up.

Note the vertical-* repos were already being autodiscovered by this config, so the dry-run log
on this PR is the first real look at how many blocks they carry.

Follow-ups

• Add Renovate replacement rule for Azure/naming to Workleap fork #207, the wl-terraform-* consumer wave, still open and still needs replacementVersion
  corrected 1.0.0 -> 1.0.1 before it merges.
• Remove both replacement rules once the estate is migrated.

🤖 Generated with Claude Code

[Copilot]

Copilot review overview

🟢 Approval recommended

The remaining labeling feedback is a non-blocking nit.

Review effort: Lite
Findings: None

What changed in this PR

Broadens the Terraform Renovate naming-module replacement from enterprise to vertical repositories.

Changes:

• Removes the redundant matchRepositories restriction.
• Expands coverage through existing autodiscovery filters.
• Updates the rule description for both repository families.

File	Summary
renovate-terraform.json	Expands naming-module replacement scope to enterprise and vertical repositories.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Martin Charbonneau (mcharbo)]

Dry-run results

renovate-terraform-enterprise ran 11m36s against the real estate (run 35874148342). All checks green, nothing created.

5 repos would get a renovate/azure-naming-azurerm-replacement branch:

The three verticals this PR is for:

• terraform-azurerm-vertical-compute
• terraform-azurerm-vertical-foundation
• terraform-azurerm-vertical-kubernetes

Plus two enterprise repos still outstanding from #211's wave:

• terraform-azurerm-enterprise-app-configuration
• terraform-azurerm-enterprise-eventhub-namespace

That second pair is the useful signal: 28 of the 30 enterprise replacement PRs have landed, and those two have not. This PR does not change their behaviour — they were already in scope via matchRepositories before — they just show up again because they are still on Azure/naming/azurerm. Worth chasing separately rather than blocking this.

Note vertical-kubernetes is in the list. An earlier gh search code sweep had only turned up vertical-compute and vertical-foundation, so that is a third consumer the code search missed — consistent with the pattern from #211, where the sweep found 30 repos against code search's 18.

Review gate on each downstream PR is unchanged: random_string destroys only, 0 creates, 0 replacements, no moved blocks, and grep -rn "name_unique\|unique-seed" clean per repo.