-
Notifications
You must be signed in to change notification settings - Fork 811
fix: handling registry module resource derived types in params file #18661
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Test this change out locally with the following install scripts (Action run 20732188677) VSCode
Azure CLI
|
Dotnet Test Results 102 files - 51 102 suites - 51 38m 57s ⏱️ - 23m 41s Results for commit aff03fa. ± Comparison against base commit 50ca350. This pull request removes 1949 and adds 662 tests. Note that renamed tests count towards both. |
|
Hey, Microsoft, is 3 weeks not enough time to just approve a fix to the nasty bug you've introduced? |
Fixes #18420
Description
This change ensures
bicepparamfiles honor resource-derived parameter types when consuming OCI or template-spec modules by resolving any unresolved resource-derived metadata from compiled module parameters through the localResourceDerivedTypeResolver, eliminating BCP033 diagnostics for patterns likeresourceInput<'Microsoft.Network/routeTables'>.properties.routes?.The fix is implemented in
DeclaredTypeManagerso parameter assignment types pulled via using benefit from the same resource-derived resolution as in-module consumption, and I added an integration test that publishes a mock registry module with a resource-derived parameter, consumes it from a params file, and asserts no diagnostics to prevent regressions.Checklist
Microsoft Reviewers: Open in CodeFlow