Bug 2025695 - landoscript: extend version_bump to handle JSON manifests

[JohanLorenzo]

Bug 2025695

Summary

• Extends version_bump to handle JSON manifests: adds browser/extensions/newtab/manifest.json to ALLOWED_BUMP_FILES, makes next_version optional for JSON files (auto-computed by bumping minor), and uses json.loads/json.dumps for replacement
• Adds JSON_MANIFEST_BUMP_FILES frozenset to gate JSON-specific code paths to explicitly listed files only
• Extracts parse_manifest_version() and apply_manifest_version_bump() as independently unit-testable pure functions (in test_version_bump_json_manifest.py)

Merge order

1. mozilla-releng/fxci-config #912 — merged ✓
2. mozilla-releng/fxci-config #933 — merged ✓ (scope name update)
3. mozilla-services/cloudops-infra #6835 (dev) — merged ✓
4. mozilla-services/cloudops-infra #6848 (chart secret) — merged ✓
5. k8s-sops: dev worker secrets — done ✓
6. mozilla-releng/k8s-autoscale #264 (dev) — merged ✓
7. This PR — land on dev-landoscript (done), then merge to master
8. mozilla-services/cloudops-infra #6838 (prod) — merge + deploy
9. k8s-sops: prod worker secrets — manual step
10. mozilla-releng/k8s-autoscale #266 (prod) — merge
11. mozilla-extensions/xpi-manifest #271 — merge last

Verification

• Unit tests: 105 pass (uv run pytest in landoscript/)
• Staging end-to-end test via local landoscript (CoT disabled): fetched manifest.json from staging-firefox, bumped 150.1.0 → 150.2.0, submitted to staging Lando, got LANDED status
• Staging XPI release via Ship-It staging: version-bump task BRV3TeLXT8S1wONrxgN7_g completed successfully on xpi-1-lando-dev worker, landing this commit on staging-firefox:

  fetching bump files from github
  browser/extensions/newtab/manifest.json: successfully bumped!
  -  "version": "151.3.0",
  +  "version": "151.4.0",
  Not a dry run...submitting lando actions
  submitting POST request to https://stage.lando.nonprod.webservices.mozgcp.net/api/repo/staging-firefox-main
  success! got 200 response with 'LANDED' status
  

[jcristau]

I don't love that this is an entirely new ad-hoc action. Couldn't we re-use the existing version_bump and tag actions?

[JohanLorenzo]

I don't love that this is an entirely new ad-hoc action. Couldn't we re-use the existing version_bump and tag actions?

Discussed over Element. We agreed on reusing version_bump now and, in a follow-up, safeguard files via scopes. This way, we avoid to scope-creep this set of PRs.

[bhearsum]

I don't necessarily disagree that it's good to have this in the same file, but I can't help but notice that at least the current implementation has two notable departures from the main code path (a special way to create "next" versions and a special way to do the replacement). This is likely to lead to maintenance and comprehensibility problems later, especially if/when we add more cases like this.

Bubbling these sorts of branches up as high as possible would be one way to improve the situation. Rearchitecturing/refactoring to generalize the idea of filename-specific bumping methods might be another, eg: perhaps associating filenames with bump version generation and bump methods.

[jcristau]

Agree with Ben on the extra code seeming unnecessary.

[JohanLorenzo]

Thanks for the reviews! How does this simpler approach look?

[bhearsum]

If we're not using a parser to write there's no good reason to use it to read either IMO. If we care about the risk of updating the wrong substring in the file the previously reviewed version of this is preferable. If we're using simple string replacement, this is unnecessary.