[release/8.0] Uses new Azure.Provisioning packages which have been split by resource #3462
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Co-authored-by: Eric Erhardt <[email protected]>
dotnet-issue-labeler
bot
added
the
area-integrations
danmoseley
added
Servicing-approved
davidfowl
approved these changes
Apr 8, 2024
mitchdenny
approved these changes
Apr 8, 2024
Closed
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport of #3383 to release/8.0
/cc @mitchdenny
Customer Impact
Reaction to provisioning package break up.
Azure Provisioning recently split out packages for the different resource types/providers. This is the way that it is intended to ship for GA. We've adopted this for P6 and we'll switch to non preview packages just before we GA. The updated packages incorporate a number of fixes around resource name generation which is why a bunch of the test cases/generated manifests need to be updated since they are baselines.
Change ASPIRE0001 to AZPROVISION001
As part of this change, we migrated from the ASPIRE0001 code analysis working code to AZPROVISION001 ... adopting the same one in our APIs that expose the CDK types so that customers only need to use one suppression.
Firewall tweaks
We now setup default firewall configurations on SQL Server and Postgres. Other resource types have picked up some extra Bicep as a side effect of some fixes in the CDK to allow setting these firewall rules. Unfortunately, we couldn't setup firewall rules for many of the other resources.
Autogenerate workspace for AppInsights
Through some manual testing I found an edge case that I hadn't tested earlier in relation to integration of log analytics and app insights. If someone does not provide a log analytics workspace explicitly then we were not creating one (we used to with our Bicep based approach). This was not an issue for deployment with AZD because it would inject the log analytics workspace ID. However if you don't provide a workspace AND you use the Azure Provisioner the deployment would fail. This PR includes fixes for that issue as well as covering test cases so that we don't accidentally regress this behavior.
Testing
Both manual testing of deployments to Azure via AZD and Azure provisioning. Also added some extra test cases to cover testing Bicep against a baseline depending on whether it is in publish or run mode (since there are sometimes some subtle differences).
Risk
Multiple changes in one PR, this isn't just the package split up PR, however the package split up change and the firewall change are interdependent (the fixes were only in the split packages).
Regression?