[automated] Open a dedicated Nix manifest PR after stable releases
- Dominant language
- C#
- Stars
- 6.3k
- Forks
- 991
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 196
Description
### Is there an existing issue for this?
- [x] I have searched the existing issues
### Is your feature request related to a problem? Please describe the problem.
The stable release pipeline already verifies and publishes the Aspire CLI archives and generates `eng/nix/versions.json`, but it commits the manifest into the same PR as `PackageValidationBaselineVersion`. That broad baseline PR can be delayed by unrelated package-validation and full-matrix failures, leaving `main`'s public Nix flake pinned to an older stable CLI.
For 13.5.2, the release assets and Nix-generation workflow completed successfully, but the generated manifest remained in #19589 while `main` continued serving 13.4.6 through `nix run github:microsoft/aspire#aspire-cli`.
### Describe the solution you'd like
When a non-prerelease GitHub release is published, automatically generate `eng/nix/versions.json` from the published `.sha512` assets and open or update a dedicated, narrow Nix manifest PR.
The workflow should:
- Run only for stable `x.y.z` releases after the release assets are publicly available.
- Generate the concrete versioned URLs and SRI hashes with `eng/nix/update-versions.sh`.
- Change only the Nix manifest and any directly related generated metadata.
- Be idempotent when the manifest already points to that release.
- Keep the Nix package version independent of `PackageValidationBaselineVersion`.
- Update the release-process and Nix packaging documentation to describe the independent PR flow.
### Additional context
The 13.5.2 internal release build uploaded and verified the CLI assets, then successfully dispatched the Nix update workflow: https://github.com/microsoft/aspire/actions/runs/32536914649.
PR #19642 is the manual catch-up for the Nix manifest. The follow-up automation should prevent future stable releases from requiring a manual bump.
Contributor guide
Research direction
Start with eng/nix/update-versions.sh and eng/nix/versions.json, then inspect the stable release workflow and the manual catch-up in PR #19642. Done means stable x.y.z releases generate the manifest from published .sha512 assets, open or update an independent narrow PR idempotently, and document the release flow and Nix packaging process.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, shell
- Domain
- devops, documentation, release
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100