Add live tests

[heaths]

Resolves #14

[heaths]

@ellismg @savannahostrowski you might be interested in this. I discovered output variables are written to the .env file and was able to use that to load .env files to support live testing.

It was a bit of a surprise that when I ran azd down the .env file and its parent directory e.g., .azure/azcryptotmp, remained such that live tests would eventually time out. Should this environment directory be remoted when the environment is deprovisioned? Or is it retained for some scenarios? Since the RG and any resources are re-provisioned anew, I can't immediately fathom a reason to keep them but may be missing some scenarios.

[ellismg]

Should this environment directory be remoted when the environment is deprovisioned? Or is it retained for some scenarios? Since the RG and any resources are re-provisioned anew, I can't immediately fathom a reason to keep them but may be missing some scenarios.

I guess we just always thought of destroying the infrastructure of the environment as a separate operation from deleting the environment itself. We have seen cases where folks with azd down and then azd up again, in the same environment, perhaps after making some modifications to AZURE_LOCATION (this is common where the initial location you pick is at capacity).

We do remove any outputs that were written to the .env file due to bicep outputs from the .env file when you run azd down. There was a bug where that was not happing for a period of time, but it was fixed for the 1.0.0 release. You could use this behavior, in combination with a sentinel output in your main.bicep to detect this case, perhaps?

[heaths]

By sentinel output, do you mean like some file to note whether the system is provisioned (or at least that up was run) or not (or that at least down was run, likely the absence of said sentinel)? Yeah, possibly. I was hoping to avoid implementation details and just rely on any .env file.

That said, if you remove outputs I could probably use that i.e., os.Getenv("AZURE_KEYVAULT_URL") would return "" so I could assume the system isn't currently provisioned.

That said, that you leave inputs (params) in the .env file, does that mean for your default / current environment, you also read that environment's .env file in as subsequent input? Interesting.

[ellismg]

That said, if you remove outputs I could probably use that i.e., os.Getenv("AZURE_KEYVAULT_URL") would return "" so I could assume the system isn't currently provisioned.

Yeah - this is what I had in mind. If there was not already a value in the .env that you could have used for this purpose, I would have said you could add an output like "output WAS_PROVISIONED boolean = true` and then do an os.Getenv on that.