Draft
Conversation
Contributor
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 15697Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 15697" |
…219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
davidfowl
force-pushed
the
davidfowl/azure-provisioning-refactor
branch
from
d224200 to
4956a53
Compare
The controller depends on IAzureProvisioningOptionsManager which is only registered in run mode. Moving the controller registration inside the run-mode block fixes the DI resolution failure in publish/test scenarios. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…r fallback AzureProvisioner is resolved in all modes as an eventing subscriber but depends on AzureProvisioningController. Register the controller and a no-op IAzureProvisioningOptionsManager unconditionally so DI succeeds in publish/test mode. In run mode, RunModeProvisioningContextProvider overrides the no-op via AddSingleton (registered before TryAdd). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
|
Re-running the failed jobs in the CI workflow for this pull request because 1 job was identified as retry-safe transient failures in the CI run attempt.
|
Contributor
|
🎬 CLI E2E Test Recordings — 52 recordings uploaded (commit View recordings
📹 Recordings uploaded automatically from CI run #23728175797 |
Contributor
Author
|
@copilot fix the failing test |
Contributor
I investigated all Azure test classes locally and all tests pass (BicepProvisionerTests, EnvironmentResourceExtensionsTests, ResourcePreparerTests, ProvisioningContextProviderTests, DeployerTests, BicepResourceTests — 178+ tests total). I was unable to access the CI logs to identify the specific failing test due to DNS restrictions in this environment. The previous two commits (95026c9, 7bbaf1f) addressed DI resolution failures for Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR introduces
AzureProvisioningController, a serialized control loop that coordinates all run-mode Azure provisioning operations. It replaces the inline provisioning logic that previously lived inAzureProvisionerwith a channel-based queue that serializes startup provisioning, dashboard commands, CLI commands, and background drift detection through a single processing loop.Controller architecture
The controller uses a
Channel<QueuedOperation>with a single reader. Every operation — provision, reprovision, reset, change-location, change-context, delete, drift-check — is modeled as a typed intent record that gets enqueued and processed one at a time. This eliminates races between concurrent dashboard commands, CLI commands, and the periodic drift monitor.Within a provisioning pass, individual resources fan out concurrently but are ordered by dependency. Each resource gets a per-resource
ProvisioningTaskCompletionSourcethat downstream resources await before starting their own deployment. The TCS is completed through exactly two paths (CompleteProvisioning/FailProvisioning), so dependents unblock as soon as their prerequisites finish rather than waiting for the entire batch.What the provisioning stack can do now
Resource commands (per-resource):
Environment commands (all resources):
Background drift detection:
Azure resource metadata:
azure.subscription.id,azure.resource.group,azure.tenant.id,azure.tenant.domain,azure.location, andresource.source(full ARM deployment id)Location overrides:
InvalidResourceLocationconflictsOther changes
BicepProvisioner— hardened checksum reuse validation, unified Azure identity metadata across fresh/cached paths, predicted deployment-id stamping for failed resourcesRunModeProvisioningContextProvider— refactored Azure context acquisition and interactive promptingAzureResourcePreparer— wires per-resource commands into the app modelAzureProvisioningControllerin run mode (fixes DI failures in publish/test scenarios)Test coverage
Checklist
<remarks />and<code />elements on your triple slash comments?aspire.devissue: