Conversation
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 15568Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 15568" |
There was a problem hiding this comment.
Pull request overview
This PR re-enables two previously disabled CLI tests by removing their [ActiveIssue] attributes so they run again in the normal test suite.
Changes:
- Re-enabled
RunCommand_SkipsBuild_WhenExtensionDevKitCapabilityIsAvailableby removing its[ActiveIssue]marker. - Re-enabled
Banner_NotDisplayedWithNoLogoFlagby removing its[ActiveIssue]marker.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| tests/Aspire.Cli.Tests/Commands/RunCommandTests.cs | Removes [ActiveIssue] to re-enable a RunCommand unit test (but the test name no longer matches the capability logic it exercises). |
| tests/Aspire.Cli.EndToEnd.Tests/BannerTests.cs | Removes [ActiveIssue] to re-enable a banner/no-logo E2E test (but its wait condition appears inconsistent with current grouped help output). |
|
|
||
| [Fact] | ||
| [ActiveIssue("https://github.com/microsoft/aspire/issues/14321")] | ||
| public async Task RunCommand_SkipsBuild_WhenExtensionDevKitCapabilityIsAvailable() |
There was a problem hiding this comment.
This test name/assert message refers to the extension "devkit" capability, but the current build decision in DotNetAppHostProject is based on the "build-dotnet-using-cli" capability (and watch mode in extension hosts). As written, the test passes regardless of "devkit" being present (it overlaps with the next test that uses an empty capability set). Consider renaming to reflect what is actually being exercised, or changing the setup/assertions so the test specifically validates a behavior that depends on the capability being provided.
| public async Task RunCommand_SkipsBuild_WhenExtensionDevKitCapabilityIsAvailable() | |
| public async Task RunCommand_SkipsBuild_WhenBuildDotNetUsingCliCapabilityIsAvailable() |
| [Fact] | ||
| [ActiveIssue("https://github.com/microsoft/aspire/issues/14307")] | ||
| public async Task Banner_NotDisplayedWithNoLogoFlag() | ||
| { |
There was a problem hiding this comment.
Re-enabling this test will likely reintroduce the original timeout: the test body waits for help output to contain the literal text "Commands:", but the root command help is generated by GroupedHelpWriter (group headings like "App commands:", "Options:", etc.) and does not output a "Commands:" header. Consider updating the wait condition to look for stable text that is actually emitted (e.g., "Usage:" / group headings from HelpGroupStrings, or waiting for the success prompt and then asserting the banner text is absent).
JamesNK
changed the title
|
Re-running the failed jobs in the CI workflow for this pull request because 2 jobs were identified as retry-safe transient failures in the CI run attempt.
|
|
🎬 CLI E2E Test Recordings — 49 recordings uploaded (commit View recordings
📹 Recordings uploaded automatically from CI run #23524880870 |
Description
Re-enable a disabled CLI test by removing its
[ActiveIssue]attribute.Test re-enabled
RunCommand_SkipsBuild_WhenExtensionDevKitCapabilityIsAvailable(RunCommandTests.cs) — was disabled by Aspire.Cli.Tests.Commands.RunCommandTests.RunCommand_SkipsBuild_WhenExtensionDevKitCapabilityIsAvailable #14321Why it's safe to re-enable
The underlying issue was resolved by #14150 ("Build in CLI if not in extension host or extension has new build capability"). That PR refactored the build-skip logic in
DotNetAppHostProject.RunAsync:"devkit"capability viaHasCapabilityAsync(KnownCapabilities.DevKit). The check lived inRunCommanditself and had race/timing issues with the test harness."build-dotnet-using-cli"capability. Additionally, watch mode is automatically enabled for extension hosts (without--start-debug-session), meaning the build code path is never reached in this scenario. TheBuildCompletionSourcesignaling pattern also ensuresRunCommanddoesn't hang waiting for build results.The test passes locally.
Fixes #14321
Checklist