Closed timothymeyers closed 1 month ago
In your example, whether it's the first or any subsequent run, the "CONTAINER_REGISTRY_SERVER" variable is always unset. Given that it is an optional parameter, if you intend to use an existing registry from a prior run of deploy.sh or your subscription, then it's probably more appropriate to set this variable to your existing ACR login server.
If it's left unset, the Bicep file will simply generate the same unique ACR name on subsequent runs (Assuming you're using the same subscription and resource group) and will not apply any updates to your existing infrastructure. I'm not sure if there's a way to log this in Bicep.
It seems a bit counter-intuitive to check if a resource exists and to use it when the resource identifier is not provided.
Nice catch and makes a lot of sense. I'm working on a PR (#106) to clean up the logging so it's a bit clearer what is happening.
Describe the bug Note, I believe the desired result is always achieved -- we end up using the existing ACR resources if it exists. This is mostly a bash logic / logging issue and absolutely a low level nitpick.
During subsequent runs of deploy.sh, the
createAcrIfNotExists()
function has anif [ !-z
block that is not always run. If your bash session is reset between runs (e.g., my Codespace timed out and restarted!), theCONTAINER_REGISTRY_SERVER
env variable may not be set any more after the first run.To Reproduce
deploy.sh
without an ACR created (have one created for you using new autocreate logic). This will result in theCONTAINER_REGISTRY_SERVER
variable being set for you.CONTAINER_REGISTRY_SERVER
is not set. (or just unset the variable).deploy.sh
again. The output will say "Creating container registry" even though it is not actually creating a new one. Theaz deployment group create
call on line 511 will return the existing server and everything proceeds as normal.Expected behavior I would expect the script output to say it is checking for the server to exist and that an existing server was found.