Fix SupportsIntegratedSecurity Test Configuration#3887
Conversation
There was a problem hiding this comment.
Pull request overview
This draft PR investigates why Integrated Security tests are being skipped in the CI/CD pipeline. The author suspects that the Azure DevOps Library variable $(SupportsIntegratedSecurity) isn't being properly resolved, even though it should always be true. The PR hardcodes this value to true in the pipeline configuration to test whether this resolves the issue.
Changes:
- Hardcoded
SupportsIntegratedSecurity: truein 6 test configurations that use local SQL Server instances (SQL 2019 x64, SQL 2019 x86, SQL 2022 x64, SQL 2022 x86, SQL 2022 named instance, and Always Encrypted tests)
|
Details of the failing tests:
All failures are the same:
Conditions:
Converting this back to a draft while I figure this out. |
Codecov Report✅ All modified and coverable lines are covered by tests.
Additional details and impacted files@@ Coverage Diff @@
## main #3887 +/- ##
==========================================
- Coverage 74.53% 67.96% -6.57%
==========================================
Files 266 260 -6
Lines 42915 65704 +22789
==========================================
+ Hits 31987 44659 +12672
- Misses 10928 21045 +10117
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Description
We have been skipping any tests that require Integrated Security. Our PR/CI pipelines appear to intend to use an Azure DevOps Library variable
$(SupportsIntegratedSecurity), which is always true, but the tests still aren't running. This is because we use template expressions to convert the string library value to a YAML boolean parameter. But this doesn't work because the library variable$(SupportsIntegratedSecurity)isn't expanded at template expression evaluation time - it literally remains the string"$(SupportsIntegratedSecurity)".I found all of the config properties that we're using as template expansion boolean values, and this was the only one using a runtime variable, so I just hardcoded them to true/false appropriately. I left a note in the YAML to help avoid this blunder in the future.
Testing
Normal PR and CI runs will show that the associated tests are no longer being skipped. One example is
ADIntegratedUsingSSPIin the Manual Tests suite.