-
Notifications
You must be signed in to change notification settings - Fork 235
provisioning: allow for provisioning stages #5492
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
6168f58
to
2503dc8
Compare
This change allows for additional provisioning stages to be defined in azure.yaml as `infra.stages`. The following commands have been updated to reflect this change: - `provision [stage]` -- Provisioning now accepts a stage name - `env refresh` -- Refresh state from all stages by default - `env refresh --stage [stage]` -- Refresh from a stage - `down` -- Delete resources from all stages by default - `down --stage [stage]` -- Delete resources from a stage Note: Behavior of`pipeline config` is left unchanged; and will require separate treatment in a follow-up change.
2503dc8
to
06fa759
Compare
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash:
pwsh:
WindowsPowerShell install
MSI install
Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
return &cobra.Command{ | ||
Use: "provision", | ||
cmd := &cobra.Command{ | ||
Use: "provision [stage]", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are your thoughts on having an --all
flag to be able to provision all stages, similar to how azd deploy --all
deploys all services?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this concept I believe stage is referring to things like dev
, test
, prod
, etc. It would be weird for an azd provision
command to provision resources for all of these stages in a given command.
@@ -598,7 +605,8 @@ func (p *BicepProvider) Deploy(ctx context.Context) (*provisioning.DeployResult, | |||
} | |||
|
|||
deploymentTags := map[string]*string{ | |||
azure.TagKeyAzdEnvName: to.Ptr(p.env.Name()), | |||
azure.TagKeyAzdEnvName: to.Ptr(p.env.Name()), | |||
azure.TagKeyAzdStageName: &p.stage, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What value are we setting the azd-stage-name
tag to for the "default" stage (the one provisioned by running azd provision
)?
Just trying to understand how this works with the changes in cli/azd/pkg/infra/deployment_manager.go
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good start but have a couple questions:
In your example you show app
as a stage. The term app
feels like a layer to me and tags like dev, test & prod seem more appropriate as a stage.
Are we mixing the 2 constructs? Let's discuss.
return &cobra.Command{ | ||
Use: "provision", | ||
cmd := &cobra.Command{ | ||
Use: "provision [stage]", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For this concept I believe stage is referring to things like dev
, test
, prod
, etc. It would be weird for an azd provision
command to provision resources for all of these stages in a given command.
global *internal.GlobalCommandOptions | ||
internal.EnvFlag | ||
} | ||
|
||
func (er *envRefreshFlags) Bind(local *pflag.FlagSet, global *internal.GlobalCommandOptions) { | ||
local.StringVarP(&er.hint, "hint", "", "", "Hint to help identify the environment to refresh") | ||
local.StringVarP(&er.stage, "stage", "", "", "Stage to refresh the environment from.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is an environment associated with a stage? Is it just the usage of the --stage
attribute during provision commands right now?
This change allows for additional provisioning stages to be defined in azure.yaml as
infra.stages
.The following commands have been updated to reflect this change:
provision [stage]
-- Provisioning now accepts a stage nameenv refresh
-- Refresh state from all stages by defaultenv refresh --stage [stage]
-- Refresh from a stagedown
-- Delete resources from all stages by defaultdown --stage [stage]
-- Delete resources from a stageNote: Behavior of
pipeline config
is left unchanged; and will require separate treatment in a follow-up change.Example
Example azure.yaml that incorporates stages and workflows:
UX
env refresh
provision
down