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?