Improve hook script debugging/troubleshooting

[charris-msft]

• Make sure you've installed the latest version using instructions in the wiki

Output from azd version
Run azd version and copy and paste the output here:
azd version 0.6.0-beta.2 (commit c4a201e)

Describe the issue
I'm creating a new template that includes multiple resources (web apps, postgres servers, databases, etc.) and I need to run a postprovision script to connect the resources with service connector. As I am iterating, there are various changes I'm making to both the bicep files and the postprovision script that I would like to test.

However, testing my changes takes a significant amount of time.

For instance, if I make a small change to the postprovision script and run az provision I have to wait until the provisioning completes, which can be minutes when multiple resources are involved, before seeing the impact of my change.

To work around this, I configure the predeploy hook in the azure.yaml to run my postprovision script so I can see the results quickly by running az deploy. But I have to remember to update the azure.yaml file every time I want to do this testing which is error prone and tedious.

Expected behavior
I would like the ability to pass a flag to azd provision (or azd deploy) to tell it whether to run the provision without the hook scripts, or the hook scripts without the provisioning. Perhaps something like this:
--no-preprovision
--no-postprovision
--no-predeploy
--no-postdeploy

And corresponding flags with 'no' replaced by 'only'.
--only-preprovision
--only-postprovision
--only-predeploy
--only-postdeploy

[weikanglim]

@charris-msft Did you have issues trying to trigger the hook?

I could imagine that if I was simply trying to invoke the script with the correct state, I would do the following:

1. Run provision once to get to the right state
2. Run my script, but first by loading the azure .env file, to do that for pwsh:

azd env get-values  | % { "`$env:$_" } | Invoke-Expression

3. Then run whichever script I have defined. It should behave exactly as-if azd invoked it in postprovision

This would be another great case if azd had azd env exec | pwsh <script> that would do the above

[charris-msft]

I was thinking about reading the .env values and setting the env vars, but your example is much cleaner.

It's not as intuitive as passing a flag to azd provision|deploy, but it's certainly a reasonable workaround for v1.

Perhaps for v1 your example could be added to azd env --help?

[wbreza]

I'd agree with @weikanglim's suggestion here. Introducing flags to modify whether the commands & hooks actually runs feels like an anti-pattern and something we may want to avoid so we don't introduce confusion.

Easiest way I could think of testing this script would be outside of azd and ensuring you have the appropriate env vars sourced into your shell. Then you should just be able to execute your script in a tight inner dev loop to get to the state that you are happy with.

[charris-msft]

My suggestion of flags is purely a suggestion, but the goal is improving discoverability and speed.

For people working with a cli tool, I would imagine it's pretty common to check the help to see what options can help you complete your task, hence the flags.

And something like a flag would be much faster and more reliable than figuring out the one-liner that @weikanglim shared or setting the env vars manually.

I believe the key question comes down to whether you expect other azd users to need to test their scripts often? If so, then it makes sense to make that task easy for them.

[savannahostrowski]

@wbreza I moved this from the RC milestone to Gallium as I suspect that this is too big for the 5/18 milestone.