Add Basic and Advanced flow for Deploy Workspace Project#961
Add Basic and Advanced flow for Deploy Workspace Project#961MicroFish91 merged 44 commits intomainfrom
Basic and Advanced flow for Deploy Workspace Project#961Conversation
| // Todo: Change this to 0.0.3 later. 0.0.3 is backwards compatible anyway so this change should be fine either way. | ||
| // For some reason it's causing a block on Function side, so just keep it at 0.0.1 until we figure out why | ||
| apiVersion: '0.0.1', | ||
| apiVersion: '1.0.0', |
There was a problem hiding this comment.
Bump to 1.0.0 because we were running into issues with semver not picking up newer versions when consuming in Functions... something related to needing to start from the first major release version.
| updatePicks(context: Partial<ContainerAppCreateContext>, picks: IAzureQuickPickItem<ContainerApp>[]): void | Promise<void>; | ||
| } | ||
|
|
||
| export class ContainerAppListStep<T extends ContainerAppCreateContext> extends AzureWizardPromptStep<T> { |
There was a problem hiding this comment.
This list step is completely new (not renamed or migrated), so feel free to do a fresh-lookover
| updatePicks(context: ManagedEnvironmentCreateContext | Partial<ManagedEnvironmentContext>, picks: ManagedEnvironmentPick[]): ManagedEnvironmentPick[] | Promise<ManagedEnvironmentPick[]>; | ||
| } | ||
|
|
||
| export class ManagedEnvironmentListStep<T extends ManagedEnvironmentCreateContext> extends AzureWizardPromptStep<T> { |
There was a problem hiding this comment.
This is a more generalized version of the old DwpManagedEnvironmentListStep that can now be reused basically anywhere. There's a lot of copied over logic, but it's been refactored / generalized such that we can now inject custom pick display strategies.
| /** | ||
| * Sort and recommend managed environments that are used in local settings deployment configurations. | ||
| */ | ||
| export class ManagedEnvironmentLocalSettingsSortStrategy<T extends DeployWorkspaceProjectInternalContext> implements ManagedEnvironmentPickUpdateStrategy { |
There was a problem hiding this comment.
This was previously an internal method for sorting the picks on DwpManagedEnvironmentListStep. I've migrated that logic into this pick update strategy for injection. I've made some small improvements as well, mainly I now run all the async checks concurrently to improve the sorting performance.
| * prioritizing registries in the currently selected resource group, and highlighting the registry currently deployed to the container app if it exists. | ||
| * Registries in the same resource group are shown at the top, followed by others, and the currently deployed registry (if any) is moved to the front of the list. | ||
| */ | ||
| export class AcrDefaultSortAndPrioritizationStrategy implements AcrPickUpdateStrategy { |
There was a problem hiding this comment.
This used to be an internal method for sorting picks on AcrListStep, it is now decoupled into its own strategy. Most of the core logic being migrated here should be the same (unchanged).
| } | ||
|
|
||
| // Managed environment | ||
| if (wizardContext.managedEnvironment) { |
There was a problem hiding this comment.
All of the starting resource displaying is now handled by StartingResourcesLogStep which allows me to remove a ton of boilerplate code from this file. Now it's really only a matter of pushing in the right basic vs. advanced steps.
| */ | ||
| export function getVerifyProvidersStep<T extends ISubscriptionActionContext>(): VerifyProvidersStep<T> { | ||
| return new VerifyProvidersStep<T>([ | ||
| appProvider, |
There was a problem hiding this comment.
I believe the container app provider and the managed environment provider end up being the same so only one of the two needs to be added
|
|
||
| if (location || deployWorkspaceProjectInternalContext.resourceGroup) { | ||
| const autoSelectLocation = location ?? nonNullValueAndProp(deployWorkspaceProjectInternalContext.resourceGroup, 'location'); | ||
| await LocationListStep.setAutoSelectLocation(deployWorkspaceProjectInternalContext, autoSelectLocation); |
There was a problem hiding this comment.
In a few places I've added or switched usage to the new setAutoSelectLocation. This is because I think it's often times a safer pattern than setting the location directly. This is because setting the location manually doesn't respect when new resource providers are potentially added in the future.
2 participants
Update
deployWorkspaceProjectto better handle onboarding existing container apps. The original implementation worked to reduce prompts by making a host of assumptions, but only allowed creation of brand new resources (more or less what we do forbasiccreates). This version of the command introduces two different deployment modes which is more closely aligned with how our other extensions typically handle creation/deployment.The deployment modes are -
I also refactored list steps to be more generally reusable by allowing pick sorting / filtering to be controlled via injected strategies.
Closes #853