`azd up` ends up compiling the bicep to an ARM template twice
@vhvb1989 noticed during the hackathon that in the case of azd up we end up initializing the provisioning provider twice, because in our IoC container we register the provisioning providers and manager as transient. Because of this, we end up compiling the bicep twice during up. Once very early (before packaging starts) and then later when we actually run the logic for provision. This is because both the implementation of up and provision call initialize on the provider, and each implementation is injected a separate copy of the provider.
@wbreza mentioned that at the time there was a reason we registered these transiently (and I think I recall a discussion about that on the PR at the time) but neither of us could recall if this was still something we needed to be doing.
We should look at if we can make these values singletons and then store "have you initialized yourself" state so calling Initialize() twice doesn't compile the bice twice.
Do we have idea how long this takes? If significant, I'd say let's get this fixed soon.
@rajeshkamal5050 This seems significant. Can we need this prioritized for October?
@wbreza is this something we can get fixed for Oct 4 release?
I'd like to work on fixing this.
Part of the provisioning provider initialization process prompts the user for any missing requirements such as subscription id, location or other information required by the provisioning provider.
I believe we opted to initially include this here so that we collected required data as early as possible in the up flow vs waiting for the child provision command to be called.
This likely will work but unclear if this is the user experience we want for this scenario when an environment requirements have not been fully initialized.
Originally posted by @wbreza in https://github.com/Azure/azure-dev/pull/2844#discussion_r1350559765
This was fixed awhile back by tracking state in bicep_provider.go.