Allow setting key vault secret name & Unify API versions #335
Conversation
…e individual settings; Add key vault secret parameter to allow setting the secret name during deployment.
|
Hey @maxilampert, generally this PR looks good but I'm curious what your use-case is for renaming the secret, the key vault secret is meant to be temporary and be deleted by the end of a build, since the key vault itself is also deleted. |
Hey @JenGoldstrich, well in our case we use a fixed key vault that has been created beforehand and does not get deleted after the image build. We have some conventions in place for how secrets should be named. |
There was a problem hiding this comment.
@maxilampert thanks for that context, although this makes me think that we should be deleting the key vault secret that we create when we don't delete the key vault, I believe that's an oversight more than intentional behavior.
I have created this issue to track that #343, if this would cause disruption to your workflow let me know, but I think it should be safe to do. In the mean time I don't wanna continue to delay this PR though, and its a reasonable change to me.
I ran acceptance tests on this PR and tested a few manual builds while setting my secret name in a template, LGTM!
This PR deals with two things.
Allow setting the key vault secret name by the 'build_key_vault_secret_name' parameter. The default value is still 'packerKeyVaultSecret' if the parameter is not specified.
Unify the ARM API versions to use there latest counterparts for compute and network resources globally and remove a lot of individual settings. Should not be breaking as the APIs are available in all clouds. Minor structural cleanup of the ARM templates.