Repository navigation
Deployment State Caching should be disabled by default in CI #19736
Description
Activity
🤖 Aspire triage pass — 2026-08-27 05:21 UTC
Area:
area-deployment
Kind: feature-request (+ docs)
Repro: none — describes three CI runner scenarios narratively (lines 3–11 of the issue body); no minimal repro project
Affected version(s): not specified by reporter
Severity: S3 — edge scenario (deployment in CI with state caching) with a workaround available (CI cache action / explicit state handling)Urgency: ⚪ backlog — no milestone
Reason: feature request + docs clarification (opt-in state caching when CI / non-interactive is detected); not a regression and not S1/S2, so it stays in the backlogSuggested owner(s): Mitch Denny (@mitchdenny), backup David Fowler (@davidfowl)
Evidence:- Mitch Denny (@mitchdenny) merged Fix Kubernetes hostname publishing and routing #19430, Fix Kubernetes values for embedded environment parameters #19429, Set a default fsGroup for Kubernetes persistent volumes #19374 in
area-deployment(last ~2 weeks) and resolved-as-completed TLS FQDN discovery waits 15 minutes for skipped route-less Gateway #19217, AKS credential pipeline uses ambient Azure CLI subscription #19216, AddPersistentVolume cannot be used with AzureKubernetesEnvironmentResource #19210, [Failing test]: Aspire.Deployment.EndToEnd.Tests.AzureResourceScopeDeploymentTests.DeployExistingServiceBusWithResourceGroupAndSubscriptionScope #19173 in the same area - David Fowler (@davidfowl) merged Fix Kubernetes GetEndpoint resolving to targetPort instead of service port #18630 and closed
aspire deployfails when using Podman without Docker Compose #13315 as completed inarea-deployment - No file paths cited in the issue, so CODEOWNERS path matching did not apply
Confidence: high
Needs human?: no- Mitch Denny (@mitchdenny) merged Fix Kubernetes hostname publishing and routing #19430, Fix Kubernetes values for embedded environment parameters #19429, Set a default fsGroup for Kubernetes persistent volumes #19374 in
I hope that CI deployment isn't an edge case!
Describe the bug
In CI there are 3 scenarios:
Ephemeral runner/s
State caching is wasted IO here, it will be deleted with the runner.
Persistent runners
Each runner gets its own cache. Each deployment might run on a different runner getting either no cache or a stale cache.
Persistent runner (singular) or explict state handling.
Once you've run into the this the first time and find the docs you might use your CI provider's caching action to save/load the state between pipeline runs. The recommendation is to key a hash of the app host's (full) path, CI runners paths often include things like a build/run number, so this is likely to miss.
Additionally, the docs make it sound like the caching is only used for collecting user input interactively - but I definedly ran into problems running in CI (where there is no input) with stale state - so it'd be great if the docs could be clearer about what's actually in the state and what happens if it's missing or stale.
Expected Behavior
Deployment works reliably out of the box in CI, without unexpectedly relying on state.
Anything else?
I feel like the safest option would be requiring an opt in to deployment state caching when CI is detected, or even when !interactive.
Future work might be to allow for the state to be stored in/with each environment, eg. in an Azure Storage account or ARM metadata.