Add new step to automatically verify if the deployed container app started successfully#909
Add new step to automatically verify if the deployed container app started successfully#909MicroFish91 merged 50 commits intomainfrom
Conversation
MicroFish91
changed the title
MicroFish91
force-pushed
the
mwf/inevitable-salmon
branch
from
6b23b6e to
d5abab8
Compare
…code-azurecontainerapps into mwf/inevitable-salmon
…code-azurecontainerapps into mwf/inevitable-salmon
…inerapps into mwf/inevitable-salmon
| return !!context.containerApp; | ||
| } | ||
|
|
||
| public addExecuteSteps(): AzureWizardExecuteStep<T>[] { |
There was a problem hiding this comment.
Is there any reason to not just add this step upfront when we create the wizard?
There was a problem hiding this comment.
I was thinking, if this is just something that should always happen on create or update, there's no need to increase cognitive overhead where people need to remember to add this step. This just couples it directly to the steps that need it, and then no one ever needs to think about it again.
The main argument against it in my mind is that it obfuscates some of the logic where you can't just easily look at the wizard steps on the main command page to figure out this is being run. That said, we already obfuscate a lot of steps like that with subWizards, so I figured it's not all that different.
There was a problem hiding this comment.
That said, if the assumption of it always needing to run after create or update is wrong, then we should definitely decouple it. It's fairly low cost either way.
There was a problem hiding this comment.
Yeah, I can't think of many great arguments for or against. I was mostly thinking this as well:
The main argument against it in my mind is that it obfuscates some of the logic where you can't just easily look at the wizard steps on the main command page to figure out this is being run.
While we do end up having to obfuscate some of these steps, they all tend to be conditional subwizards which unfortunately, we can't help but do.
|
The log message and Copilot's response is pretty smexy though 🫦 |
|
I added most of the feedback, I need to test all the scenarios again just to double check everything is still good, but probably ready to review again for the most part |
|
Yeah this is awesome |
MicroFish91
force-pushed
the
mwf/inevitable-salmon
branch
from
d32361c to
982ba44
Compare
| "@azure/storage-blob": "^12.4.1", | ||
| "@fluentui/react-components": "^9.56.2", | ||
| "@fluentui/react-icons": "^2.0.265", | ||
| "@microsoft/vscode-azext-azureutils": "^3.3.3", | ||
| "@microsoft/vscode-azext-github": "^1.0.2", | ||
| "@microsoft/vscode-azext-utils": "^3.2.1", | ||
| "@microsoft/vscode-azext-utils": "^3.3.0", |
There was a problem hiding this comment.
Whoa.. any idea why there are 7273 lines of code deleted? Kind of wild.
There was a problem hiding this comment.
It's from Azure Monitor Query, it blew my mind too, I don't really understand how it led to so many lines removed lol
There was a problem hiding this comment.
Did it change the lockfile version?
There was a problem hiding this comment.
I don't think so
nturinski
left a comment
nturinski
left a comment
There was a problem hiding this comment.
Looks good! Really excited about this feature tbh
4 participants
Closes #906