fix(aspire): publish TUnit.Aspire.Core package (#6246)

[thomhurst]

Fixes #6246

Problem

TUnit.Aspire 1.55.0 fails to restore:

<PackageReference Include="TUnit.Aspire" Version="1.55.0" />

Root cause

PR #6243 split TUnit.Aspire.Core out of TUnit.Aspire and made the
TUnit.Aspire metapackage ProjectReference it — so the published
TUnit.Aspire.nupkg carries a <dependency> on TUnit.Aspire.Core.

But GetPackageProjectsModule (the explicit allowlist of projects the
pipeline packs and pushes to NuGet) was never updated to include
TUnit.Aspire.Core. The metapackage therefore shipped a dependency on a
package that doesn't exist on NuGet → restore 404.

The earlier TUnit.AspNetCore / TUnit.AspNetCore.Core split (which this
mirrored) correctly lists both projects; Aspire only listed the
metapackage.

Fix

Add Sourcy.DotNet.Projects.TUnit_Aspire_Core to the pack/push list.
Verified TUnit.Pipeline builds (the Sourcy-generated symbol resolves).

[claude]

Code Review

Status: LGTM — minimal, correct hotfix for a publish-time regression.

---

Overview

This PR fixes a NuGet restore failure caused by PR #6243 splitting TUnit.Aspire.Core out of TUnit.Aspire without adding the new project to the pipeline's publish allowlist. The metapackage shipped a dependency on a package that didn't exist on NuGet, causing restore 404s for consumers.

---

Change Analysis

File: TUnit.Pipeline/Modules/GetPackageProjectsModule.cs (+1 line)

The fix adds Sourcy.DotNet.Projects.TUnit_Aspire_Core to the explicit allowlist, directly mirroring the pre-existing TUnit_AspNetCore / TUnit_AspNetCore_Core pair — which is exactly the right pattern:

Sourcy.DotNet.Projects.TUnit_AspNetCore,
Sourcy.DotNet.Projects.TUnit_AspNetCore_Core,
Sourcy.DotNet.Projects.TUnit_Aspire,
Sourcy.DotNet.Projects.TUnit_Aspire_Core,  // <-- added

The ordering is logical and consistent with the existing convention.

---

Correctness

• Root cause is correctly identified: the metapackage declares a <dependency> on TUnit.Aspire.Core but the core package was never pushed.
• The fix is minimal and targeted — touching only the one line responsible.
• The pattern matches how the identical AspNetCore split was handled, reducing risk of error.

---

Concerns

None. This is a clean, necessary fix.

---

Suggestion (for future splits)

Given that this omission has now happened twice (once for AspNetCore, caught; once for Aspire, shipped), it may be worth adding a CI check that validates every ProjectReference in a metapackage has a corresponding entry in GetPackageProjectsModule. Something like:

// Hypothetical guard in the pipeline: assert that all
// ProjectReference targets of metapackages are in the pack list

This would catch the pattern at PR time rather than post-release. Not blocking for this fix, but worth a follow-up issue.

---

Overall: Correct, well-scoped fix with a clear PR description explaining root cause and rationale. No issues found.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}