microsoft / microsoft/aspire

[automated] Open a dedicated Nix manifest PR after stable releases

Open
#19,655 1 comment 3 reactions 0 assignees View on GitHub
area-engineering-systems needs-area-label triage:bot-seen
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.