fix: Added DependsOn to Virtual Network module to prevent Network peering to start whilst subnets are being created

[joerygrolleman]

Description

When creating a virtual network with subnets and network peering for the first time it causes an error, namely Resource is in Updating state and the last operation that updated/is updating the resource is PutSubnetOperation.. To prevent this from happening, I added a dependsOn on the peering to prevent the peering from being created before the subnets were created.

This isn't the prettiest solution as subnets are not dependent on the peerings to succeed.

Fixes #3405

Pipeline Reference

Pipeline

Type of Change

• Update to CI Environment or utilities (Non-module affecting changes)
• Azure Verified Module updates:
  • Bugfix containing backwards-compatible bug fixes, and I have NOT bumped the MAJOR or MINOR version in version.json:
    • Someone has opened a bug report issue, and I have included "Closes #{bug_report_issue_number}" in the PR description.
    • The bug was found by the module author, and no one has opened an issue to report it yet.
  • Feature update backwards compatible feature updates, and I have bumped the MINOR version in version.json.
  • Breaking changes and I have bumped the MAJOR version in version.json.
  • Update to documentation

Checklist

• I'm sure there are no other open Pull Requests for the same update/change
• I have run Set-AVMModule locally to generate the supporting module files.
• My corresponding pipelines / checks run clean and green without any errors or warnings

[AlexanderSehr]

Hey @joerygrolleman,
thanks for the contribution. 💪
I'd love to go ahead and merge it right in, but we have to do 2 things first:

1. Please run the Set-AVMModule (ref) utility on the module so that all generated files are updated (in this case this would primarily be the main.json file)
2. If possible, please add a pipeline badge of the deployment working in your fork and attach a pipeline badge to the module's description

[joerygrolleman]

@microsoft-github-policy-service agree

[AlexanderSehr]

@joerygrolleman hey, in case you have not noticed, it appears you have not disabled your workflows and recently merged a change into your main branch. Because all pipelines have a trigger on changes in main (for their corresponding paths), you have a lot of running workflows on your hand.
I'd highly encourage you to do 2 things:

1. Stop any non-running workflow if you want to free up your agents
2. Disable the workflows in main using this workflow as soon as it becomes available (GitHub seems to still register it)
   • This workflow will effectively disable all your module pipelines so that they won't trigger anymore unless you explicitely enabled them (which you can also do for an individual workflow)

For more information please see this article in our contribution guide.

The good news is that not all secrets seem to have been set up. So while all workflows do currently run, they won't deploy any services as they cannot log into Azure. In other words, they effectively only run the static validation after which they fail.

[joerygrolleman]

Hi! Thanks for the heads-up for disabling the pipelines, that helped a lot! I ran the Set-AVMModule and added a status badge for the GitHub Action

[AlexanderSehr]

Thanks for your contribution @joerygrolleman, off we go :)