Create releases from the release workflow

[Kralizek]

Summary

Align SMCP with the newer shared release flow used across the other OSS repositories.

Changes

• use dotnet-build@v0.3 in CI;
• add manual release inputs for bump, channel (stable, alpha, beta, rc), and dry-run;
• calculate manual release versions with calculate-next-version@v0.3, honoring MinVerMinimumMajorMinor;
• build and pack the calculated version before creating a GitHub release;
• create stable or prerelease GitHub releases directly from the workflow;
• validate published and newly created releases with validate-release@v0.3;
• verify the packed package version matches the selected release version;
• preserve the existing GitHub Packages, NuGet.org, and release-asset publishing behavior;
• keep support for externally published GitHub releases.

[Copilot]

🟡 Changes recommended

Release workflow issues must be addressed before approval.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Modernizes CI and release automation with shared .NET actions, manual versioning, validation, and GitHub release creation.

Changes:

• Adds manual bump, channel, and dry-run inputs.
• Calculates, builds, packs, and validates release versions.
• Preserves package and release-asset publishing.

File summaries

File	Summary
.github/workflows/release.yml	Implements the updated release flow; publication ordering, tag fetching, and duplicate-trigger handling require changes.
.github/workflows/ci.yml	Uses the shared dotnet-build@v0.2 action.

Review details

Suppressed comments (1)

.github/workflows/release.yml:185

• This command creates a published release, which immediately triggers the same workflow through the release: [published] event. The release-triggered run then executes the same package pushes and gh release upload --clobber while this manual run continues, so concurrent uploads can race and one workflow may fail; avoid publishing in both paths (for example, let the release-triggered run handle publication) while retaining the external-release path.

          gh release create "${args[@]}"

• Files reviewed: 2/2 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟡 Changes recommended

Two moderate release-workflow issues remain unresolved.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (1)

.github/workflows/release.yml:254

• Publishing this draft emits the release.published event that this same workflow listens for at lines 30-31, so every manual release starts a second full release job that rebuilds, pushes the same packages, and uploads the assets again. --skip-duplicate and --clobber mask most failures but still create redundant registry traffic and concurrent release processing; add a reliable guard/marker or separate the externally-published path from the workflow-created path.

          gh release edit "$TAG" --repo "${{ github.repository }}" --draft=false

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

Resolve the critical duplicate-publication race and moderate retry/idempotency issue in release.yml.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (1)

.github/workflows/release.yml:66

• The resumable lookup only considers drafts. If gh release edit --draft=false succeeds but the subsequent fetch or validation fails, a rerun will not find this now-published release: a stable rerun calculates the next version from the newly published tag, while a prerelease rerun can reuse the existing tag and then fail when gh release create sees the existing release. Handle an already-published release/tag for the current commit before calculating a new version, or make the post-publication path idempotent.

      - name: Detect resumable draft release
        if: github.event_name == 'workflow_dispatch' && !inputs.dry_run
        id: resumable-release

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Two unresolved moderate release-workflow issues affect dry-run validation and retry safety.

Review details

Suppressed comments (2)

.github/workflows/release.yml:123

• The dry-run path skips both the minimum-version and calculator steps because they are gated on steps.resumable-release.outputs.resume != 'true', while the resumable-release step itself is skipped for dry runs. manual-release therefore writes an empty version, so Validate package version compares the packed version with an empty expected value and fails before the dry-run summary. Allow the version calculation steps to run for dry runs as well.
  .github/workflows/release.yml:322
• Once line 317 publishes the release, this retry path is no longer resumable: the detector only matches .draft == true, so a rerun after a failure in the following fetch or validation steps skips the existing release and recalculates against its tag. Stable releases then advance to a new version, while prereleases can reuse an already-published tag and fail when creating the release. Fetch/validate the tag while the release is still a draft, or make the detector and publish steps idempotently handle an existing published release.

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Resumable-release detection can miss an existing draft after master advances.

Review details

Suppressed comments (1)

.github/workflows/scripts/detect-resumable-release.sh:24

• If the draft-creation run fails and master advances before the next manual dispatch, this SHA-only filter ignores the existing draft. The version calculator then produces the same tag from the stable baseline (or fails if the draft tag is already fetched), and the create step cannot resume the existing release. Resume should locate the incomplete draft independently of the new SHA and build/validate against that release's target commit, or otherwise provide a supported recovery path.

    '.[]
      | select(.target_commitish == $sha)
      | select(.tag_name | test($pattern))

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

Draft release reuse is not scoped to GITHUB_SHA and may publish stale source.

Get a fresh assessment by requesting another Copilot review.

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

The release workflow changes span versioning, publishing, draft resumption, and validation, warranting final human review.

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 0 new
• Review effort level: Lite

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud