Skip to content

Add workflow to validate published Aspire CLI builds#17532

Draft
radical wants to merge 4 commits into
microsoft:mainfrom
radical:radical/staging-cli-smoke-workflow
Draft

Add workflow to validate published Aspire CLI builds#17532
radical wants to merge 4 commits into
microsoft:mainfrom
radical:radical/staging-cli-smoke-workflow

Conversation

@radical
Copy link
Copy Markdown
Member

@radical radical commented May 27, 2026

Description

Adds a manually-dispatchable GitHub Actions workflow for validating a published Aspire CLI build with the full CLI E2E suite.

The existing daily smoke workflow stays small. This new workflow is the GitHub-side validation target for a later release/AzDO dispatch change: it accepts an exact Aspire CLI version, enumerates the same Aspire.Cli.EndToEnd.Tests class-split matrix used by PR validation, and runs each class as its own GitHub Actions job.

The workflow builds and loads the shared CLI E2E Docker images, installs the exact requested Aspire CLI version through the existing E2E install strategy, excludes quarantined and outerloop tests, and keeps the Microsoft.Testing.Platform no-tests exit-code handling used by the main test runner.

The workflow was hardened with pinned actions, contents: read, disabled checkout credential persistence, and env-based shell inputs to avoid direct template expansion in scripts.

Validation:

zizmor --offline --no-progress --format plain .github/workflows/validate-published-build.yml
No findings to report. Good job! (8 suppressed)
ruby -e 'require "yaml"; YAML.load_file(".github/workflows/validate-published-build.yml")'

Local matrix generation confirmed 64 Aspire.Cli.EndToEnd.Tests class entries.

Fixes # (issue)

Checklist

  • Is this feature complete?
    • Yes. Ready to ship.
    • No. Follow-up changes expected.
  • Are you including unit tests for the changes and scenario tests if relevant?
    • Yes
    • No
  • Did you add public API?
    • Yes
      • If yes, did you have an API Review for it?
        • Yes
        • No
      • Did you add <remarks /> and <code /> elements on your triple slash comments?
        • Yes
        • No
    • No
  • Does the change make any security assumptions or guarantees?
    • Yes
      • If yes, have you done a threat model and had a security review?
        • Yes
        • No
    • No

radical and others added 4 commits May 27, 2026 02:11
The daily CLI smoke workflow only ran classes matching *SmokeTests and
installed the dev daily channel by default. That left most CLI end-to-end
coverage out of the daily signal and did not exercise the staging channel.

Change the workflow dispatch default to staging, enumerate the CLI E2E
class-split matrix, and run each test class as its own matrix job. The
matrix jobs load the prebuilt CLI E2E Docker images and pass
ASPIRE_E2E_QUALITY through so the tests install the requested daily channel
instead of using source-built CLI artifacts.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The daily workflow runs outside pull request events, so the CLI E2E project
is skipped during test enumeration unless the workflow explicitly overrides
that skip. Without this, the generated class matrix is empty even though the
workflow asks to include CLI E2E tests.

Pass SkipTests=false when building the daily matrix so the CLI E2E project
emits its class partitions for the staging daily workflow.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The full CLI E2E validation should run as a post-publish check instead of
expanding the scheduled daily smoke workflow. Daily smoke stays focused on
its small smoke-test subset, while validate-published-build enumerates the
same class-split CLI E2E matrix used by PR validation and runs each class as
its own GitHub Actions job against the selected install-script quality.

Wire the internal Azure DevOps build to dispatch the new workflow after the
WinGet and Homebrew installer preparation jobs complete. The trigger reuses
the existing GitHub App dispatch helper from the release pipeline, maps
stable installer builds to the release quality and prerelease builds to the
staging quality, and waits for the GitHub Actions run to finish.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Move the published-build validation branch back to a GitHub-only change by
removing the Azure DevOps dispatch wiring from this branch. The new workflow
remains manually dispatchable and validates an exact published Aspire CLI
version, with the CLI E2E tests split by class to match PR validation shape.

Harden the workflow based on self-review by avoiding direct template
expansion in shell scripts, disabling checkout credential persistence during
matrix setup, and preserving the MTP no-tests exit-code handling used by the
main test runner.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@github-actions
Copy link
Copy Markdown
Contributor

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 17532

Or

  • Run remotely in PowerShell:
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 17532"

@github-actions
Copy link
Copy Markdown
Contributor

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.
GitHub was asked to rerun all failed jobs for that attempt, and the rerun is being tracked in the rerun attempt.
The job links below point to the failed attempt jobs that matched the retry-safe transient failure rules.

Matched test failure patterns (1 test)
  • Aspire.Cli.EndToEnd.Tests.KubernetesDeployWithValkeyTests.DeployK8sWithValkey — Unable to access container registry during publish

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant