updating envd to use release-please

[charlie-e2b]

1. .release-please-manifest.json — set packages/envd to 0.6.13 to match the real current version in version.go. Release-please treats the manifest as the source of truth for "last released version," so the next release PR will compute the next version from this (e.g. 0.6.14 for fixes, 0.7.0 for feats, per conventional commits).
2. release-please-config.json — added "extra-files": ["pkg/version.go"] to the envd package. Paths in extra-files are relative to the package directory, so this points at packages/envd/pkg/version.go.
3. packages/envd/pkg/version.go — appended the magic comment release-please's generic updater looks for:
   const Version = "0.6.13" // x-release-please-version
4. On every release PR, release-please scans files listed in extra-files and rewrites the semver string on any line tagged with that comment. So the PR will bump the changelog, the manifest, and this constant together, and merging the PR keeps everything in sync automatically. Developers never touch the file again.

Two things to be aware of:

• Release-please determines the commit range for the changelog by looking for the tag matching the manifest version — envd-v0.6.13 with your config. If your past releases weren't tagged that way (the manifest previously said 0.0.1), the first release PR after this change may pull older commits into the changelog. That's cosmetic and self-corrects after one release, but you can also push an envd-v0.6.13 tag at the appropriate commit to get a clean range.
• The same pattern works for the other packages (orchestrator, api, etc.) if they grow version files — just add extra-files and the annotation.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[claude]

Additional findings (outside current diff — PR may have been updated during review):

• 🔴 .release-please-manifest.json:5-13 — Unresolved git merge-conflict markers (<<<<<<< Updated upstream, =======, >>>>>>> Stashed changes) were committed into .release-please-manifest.json (lines 5-13), and the same markers appear in release-please-config.json inside the packages/envd block. Both files are now invalid JSON, so release-please (and any JSON parser) will fail to parse them on every run, breaking the release automation this PR is trying to set up.

  Extended reasoning...

  Both .release-please-manifest.json and release-please-config.json contain literal, unresolved git merge-conflict markers committed as file content. In the manifest:

  <<<<<<< Updated upstream
    "packages/envd": "0.0.1"
  =======
    "packages/envd": "0.6.13",
    "packages/orchestrator": "0.0.0",
    "packages/api": "0.0.0",
    "packages/dashboard-api": "0.0.0",
    "packages/nomad-nodepool-apm": "0.0.0"
  >>>>>>> Stashed changes
  }

  and the same three tokens (<<<<<<< Updated upstream, =======, >>>>>>> Stashed changes) appear inside the packages/envd object in release-please-config.json, straddling the new changelog-path/extra-files keys and several other package entries (orchestrator, api, dashboard-api, nomad-nodepool-apm).

  Why this breaks things: <<<<<<<, =======, and >>>>>>> are not valid JSON tokens under any grammar — they're raw text left behind from an interactively-resolved git stash pop or rebase conflict that was never cleaned up before committing. Any standard JSON parser (JSON.parse, encoding/json, jq, etc.) will throw a syntax error the instant it hits the first < after the third package entry.

  Concrete proof / step-through:

  1. release-please runs as a GitHub Action on this repo's CI.
  2. On startup it reads .release-please-manifest.json to determine "last released version" per package, and release-please-config.json to determine package configuration (release-type, extra-files, etc.).
  3. Both reads go through a JSON parser. Feeding either file to jq . or Node's JSON.parse today reproduces the failure directly: jq: error: Unmatched '<': syntax error, unexpected '<', expecting '}'... at line 5, column 0.
  4. Because the manifest is release-please's single source of truth for every package's last-released version, this isn't scoped to envd — the parse failure aborts the whole release-please invocation, so no package (docker-reverse-proxy, client-proxy, clickhouse, etc.) gets release PRs generated until this is fixed.

  Why nothing else catches this before merge: these are plain JSON config files, not compiled or type-checked, and apparently no CI step runs jq/schema validation against them pre-merge — so the parse error would only surface the first time release-please's workflow actually runs post-merge.

  The fix is to resolve the conflict properly rather than keep both sides: keep "packages/envd": "0.6.13" (matching the PR's stated goal of aligning the manifest with the real current version in version.go), and drop the four extra package entries (orchestrator, api, dashboard-api, nomad-nodepool-apm) and the "Updated upstream" side entirely, since the PR description only ever mentions configuring release-please for envd. The same resolution — deleting the marker lines and picking one side — applies to the matching block in release-please-config.json, keeping the extra-files: ["pkg/version.go"] addition but dropping the unrelated new package blocks unless they're actually intended as part of this change.