Refactor config + file funcs for deploymentStack#221
Refactor config + file funcs for deploymentStack#221haysch wants to merge 3 commits intoAzure:mainfrom
Conversation
Currently, the deploymentStack configuration parsing is too strict in terms of requirements, i.e., `deny-settings-mode` does not exists for `delete` action. In addition, the deploymentStack scope can be optionally specified for `delete` action, however, the Azure Deployment Stack client does not currently expose a `beginDeleteAtTenantScopeAndWait` similar to Azure Deployment client, thus, the highest level of deletion is at `SubscriptionScope` without a specified subscription ID, which seems to be akin to `TenantScope`.
|
Hi @SydneyhSmith, an attempt to fix some of the inconsistencies. I found that the If there are any changes required or questions please let me know! |
When working with deploymentStack, providing a template is not required when using the `delete` action and can cause confusion. This commit introduces a flag that determines whether or not a missing template file is valid. The default value is assumed to be `true` as it seems to have been the case historically.
Ensure that the description and example is up-to-date.
ffaacfa to
d14ba50
Compare
|
|
||
| This workflow runs on manual dispatch. It checks out the code, logs into Azure, and deletes a "Development" deployment stack in the `westus2` region using the specified template and parameters files. | ||
| This workflow runs on manual dispatch. It checks out the code, logs into Azure, and deletes the "Development" deployment stack at the provided scope. | ||
| Without a defined scope, the operation is executed at highest possible level. |
There was a problem hiding this comment.
I am a bit unsure on what exactly happens when I cannot test not providing a scope/ID.
There was a problem hiding this comment.
Is there a reason we don't want to require the scope to be defined if we are attempting to match az stack commands? In the docs, there are separate commands for each scope: az stack group delete, az stack mg delete, az stack sub delete
There was a problem hiding this comment.
I think is the biggest gap in my knowledge/experience. Now that you point it out it makes sense.
In which case, if - for example - no resource group/ID is specified for az stack group, it would likely default to the default subscription (?)
There was a problem hiding this comment.
I believe either resource group and name need to be provided or the stack resource id from looking at the examples and the error when trying az stack group delete: "Please enter the (stack name and resource group) or stack resource id".
There was a problem hiding this comment.
That seems to be completely correct! I wonder why the stack docs are a bit more vague compared to az deployment - likely because it's much newer I imagine.
Will update the PR to require scope.
The current setup has some strict, and unnecessary, requirements for deploymentStack's
deleteaction.This PR aims to relax the requirements and bring the GH Action in line with the
az stack group <create|delete|validate>documentation in terms of required/optional/unnecessary parameters.Fixes #207