Closed sopelt closed 2 years ago
Thanks for bringing this to our attention. We will investigate it further and update you shortly.
@sopelt - Thanks for bringing this to our attention. I'm going to assign this to the document author so they can update the document accordingly.
@sopelt - thanks for this feedback. I was able to reproduce the issue of concurrent deployments with a static module name and the same scope interfering with the output. I'll add clarification to the article.
I have added clarification to the article. It might be Monday morning before it is published.
The documentation should clarify the requirements for
<linked-deployment-name>
as there seem to be unexpected side-effects when deployment names are not unique in concurrent ARM operations. Without the clarification we have to assume that the name of the deployment might have to be unique to avoid "spilling links/output" between different top-level deployments.An example (derived from a real-world scenario):
scope
)name: 'cnameDeployment'
) two different top-level deployments seem to reference the same CNAME module invocation which spills the output from one stage to another.I assume that combining the
deployment().name
to the module deployment name (e.g.name: '${deployment().name}-cname'
) should resolve this issue given that we use unique release IDs as the top-level deployment name.I think that this quickstart sample might face this issue. I assume that when
main.bicep
is deployed concurrently the nestednested.flowlogs.bicep
is only executed once and referenced asdeployFlowLogs
.In the "best case" it seems that concurrent deployments with non-unique nested deployments cause conflicts and fail. The more problematic case would be creation/configuration of resources with wrong values spilled from other deployments.
A clarification and documented best practices for naming modules/nested deployments would be great.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.