-
Notifications
You must be signed in to change notification settings - Fork 321
DRI | Fix AKV Official Build; Sign Less DLLs #3909
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
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR addresses two issues in the official build pipelines: fixing the AKV build failures caused by version mismatches, and optimizing the DLL signing process to reduce build times.
Changes:
- Updated MDS package version from 6.1.1 to 7.0.0-preview3.25342.7 and corresponding AKV version numbers from 6.1.1 to 7.0.0-preview3 to resolve System.Text.Json dependency conflicts
- Refactored ESRP signing process for AKV by splitting the monolithic signing step into separate DLL and NuGet signing steps with parameterized file patterns
- Tightened DLL signing patterns in both AKV (to
Microsoft.Data.SqlClient.AlwaysEncrypted.*.dll) and MDS pipelines (toMicrosoft.Data.SqlClient*.dll) to avoid signing unnecessary dependencies
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| eng/pipelines/variables/akv-official-variables.yml | Updated mdsPackageVersion to 7.0.0-preview3.25342.7 and updated version variables (major/minor/patch/preview) to align with the new MDS version |
| eng/pipelines/steps/compound-esrp-dll-signing-step.yml | New parameterized step for DLL signing with configurable pattern parameter, extracted from compound-esrp-code-signing-step.yml |
| eng/pipelines/steps/compound-esrp-nuget-signing-step.yml | New dedicated step for NuGet package signing, extracted from compound-esrp-code-signing-step.yml |
| eng/pipelines/steps/compound-esrp-code-signing-step.yml | Deleted - functionality split into separate DLL and NuGet signing step files |
| eng/pipelines/jobs/build-akv-official-job.yml | Updated to use new signing steps with specific pattern for AKV DLLs (Microsoft.Data.SqlClient.AlwaysEncrypted.*.dll) |
| eng/pipelines/common/templates/steps/esrp-code-signing-step.yml | Tightened DLL signing pattern from *.dll to Microsoft.Data.SqlClient*.dll for MDS pipeline |
| src/Microsoft.Data.SqlClient.sln | Added new pipeline files to solution for better visibility in IDE |
Description
This PR targets two small changes to our official pipelines:
Fix AKV Official Build
The AKV official pipeline was encountering some failures. These appear to be due to the version of System.Text.Json having been downgraded in our central feed (Directory.Packages.props) while the MDS version the build was targeting was not changed - and was still stuck on 6.1.1. When the restore task runs, AKV project would target MDS 6.1.1 which uses System.Text.Json v9.something, but because the central feed has it pinned to v8.something. The fix was easy - update the MDS version to target the latest preview release of MDS.
This does introduce some questions about how do we sequence package dependency updates. But that's outside the scope of this quick fix.
Sign Less DLLs
During investigation of the above, I saw some of the builds were failing because signing the DLLs was timing out. Although these are transient issues, we noticed there are a lot of DLLs being signed, including DLLs we never will release (ie, dependencies like System.Text.Json). This seems excessive and wasting time and resources.
To resolve this, I've tightened up the pattern property in the ESRP signing tasks to target the relevant DLLS. However, because the MDS and AKV pipelines have diverged, this was tackled in two different manners.
Issues
N/A - internally tracked DRI tasks
Testing
Launched a couple pipelines on internal ADO, and they pass