Introduce Logging package and rework official pipelines#3967
Introduce Logging package and rework official pipelines#3967cheenamalhotra wants to merge 56 commits intomainfrom
Conversation
2d6835f to
ec31d8d
Compare
| <_OurAssemblyFileVersion Condition="'$(AbstractionsAssemblyFileVersion)' == '' and '$(AbstractionsPackageVersion)' != ''">$(AbstractionsPackageVersion.Split('-')[0])</_OurAssemblyFileVersion> | ||
| <!-- If neither property is set, use the default value.--> | ||
| <_OurAssemblyFileVersion Condition="'$(AbstractionsAssemblyFileVersion)' == '' and '$(AbstractionsPackageVersion)' == ''">$(AbstractionsDefaultMajorVersion).0.0.$(BuildNumber)</_OurAssemblyFileVersion> | ||
| <_OurAssemblyFileVersion Condition="'$(AbstractionsAssemblyFileVersion)' == '' and '$(AbstractionsPackageVersion)' == ''">$(AbstractionsDefaultMajorVersion).0.0.$(AssemblyBuildNumber)</_OurAssemblyFileVersion> |
There was a problem hiding this comment.
The AssemblyBuildNumber property is used here but is defined in tools/props/Versions.props. This creates an import order dependency: Versions.props must be imported before this file for AssemblyBuildNumber to be defined. Verify that the import order in all consuming projects ensures Versions.props is imported first, or consider defining a fallback value here if AssemblyBuildNumber is empty.
| <_OurAssemblyFileVersion Condition="'$(AzureAssemblyFileVersion)' == '' and '$(AzurePackageVersion)' != ''">$(AzurePackageVersion.Split('-')[0])</_OurAssemblyFileVersion> | ||
| <!-- If neither property is set, use the default value.--> | ||
| <_OurAssemblyFileVersion Condition="'$(AzureAssemblyFileVersion)' == '' and '$(AzurePackageVersion)' == ''">$(AzureDefaultMajorVersion).0.0.$(BuildNumber)</_OurAssemblyFileVersion> | ||
| <_OurAssemblyFileVersion Condition="'$(AzureAssemblyFileVersion)' == '' and '$(AzurePackageVersion)' == ''">$(AzureDefaultMajorVersion).0.0.$(AssemblyBuildNumber)</_OurAssemblyFileVersion> |
There was a problem hiding this comment.
The AssemblyBuildNumber property is used here but is defined in tools/props/Versions.props. This creates an import order dependency: Versions.props must be imported before this file for AssemblyBuildNumber to be defined. Verify that the import order in all consuming projects ensures Versions.props is imported first, or consider defining a fallback value here if AssemblyBuildNumber is empty.
| <!-- If LoggingPackageVersion is set, use its trimmed value. --> | ||
| <_OurAssemblyFileVersion Condition="'$(LoggingAssemblyFileVersion)' == '' and '$(LoggingPackageVersion)' != ''">$(LoggingPackageVersion.Split('-')[0])</_OurAssemblyFileVersion> | ||
| <!-- If neither property is set, use the default value.--> | ||
| <_OurAssemblyFileVersion Condition="'$(LoggingAssemblyFileVersion)' == '' and '$(LoggingPackageVersion)' == ''">$(LoggingDefaultMajorVersion).0.0.$(AssemblyBuildNumber)</_OurAssemblyFileVersion> |
There was a problem hiding this comment.
The AssemblyBuildNumber property is used here but is defined in tools/props/Versions.props. This creates an import order dependency: Versions.props must be imported before this file for AssemblyBuildNumber to be defined. Verify that the import order in all consuming projects ensures Versions.props is imported first, or consider defining a fallback value here if AssemblyBuildNumber is empty.
| <PackageVersion | ||
| Include="Microsoft.Data.SqlClient.AlwaysEncrypted.AzureKeyVaultProvider" | ||
| Version="$(AkvPackageVersion)" /> | ||
| <PackageVersion | ||
| Include="Microsoft.Data.SqlClient.Extensions.Abstractions" | ||
| Version="$(AbstractionsPackageVersion)" /> | ||
| <PackageVersion | ||
| Include="Microsoft.Data.SqlClient.Extensions.Azure" | ||
| Version="$(AzurePackageVersion)" /> | ||
| <PackageVersion | ||
| Include="Microsoft.Data.SqlClient.AlwaysEncrypted.AzureKeyVaultProvider" | ||
| Version="$(AkvPackageVersion)" /> | ||
| Include="Microsoft.Data.SqlClient.Extensions.Logging" | ||
| Version="$(LoggingPackageVersion)" /> |
There was a problem hiding this comment.
The package ordering has been changed to place Microsoft.Data.SqlClient.AlwaysEncrypted.AzureKeyVaultProvider before the Extensions packages. For consistency with the rest of the file (alphabetical ordering within logical groups), consider either keeping the original order or documenting the reason for this specific ordering if it's intentional.
build.proj
Outdated
| <Target Name="BuildAll" DependsOnTargets="BuildNetFx;BuildNetCore;BuildNetStandard" /> | ||
| <Target Name="BuildAllConfigurations" DependsOnTargets="Restore;BuildTools;BuildSqlServerLib;BuildNetFx;BuildNetCoreAllOS;BuildNetStandard;GenerateMdsPackage" /> | ||
| <Target Name="BuildAll" DependsOnTargets="BuildNetFx;BuildNetCore;BuildNetStandard;BuildLogging;BuildAzure" /> | ||
| <Target Name="BuildAllConfigurations" DependsOnTargets="Restore;BuildTools;BuildSqlServerLib;BuildNetFx;BuildNetCoreAllOS;BuildNetStandard;BuildLogging;BuildSqlServerPackage;GenerateMdsPackage" /> |
There was a problem hiding this comment.
The PackAbstractions target was split out from BuildAbstractions, but the BuildAllConfigurations target chain doesn't appear to call PackAbstractions, PackLogging, or PackAzure. This means the Pack step won't run during BuildAllConfigurations. Verify whether this is intentional or if these Pack targets should be added to the dependency chain.
| <Target Name="BuildAllConfigurations" DependsOnTargets="Restore;BuildTools;BuildSqlServerLib;BuildNetFx;BuildNetCoreAllOS;BuildNetStandard;BuildLogging;BuildSqlServerPackage;GenerateMdsPackage" /> | |
| <Target Name="BuildAllConfigurations" DependsOnTargets="Restore;BuildTools;BuildSqlServerLib;BuildNetFx;BuildNetCoreAllOS;BuildNetStandard;BuildLogging;BuildSqlServerPackage;GenerateMdsPackage;PackAbstractions;PackLogging;PackAzure" /> |
| - template: /eng/pipelines/common/templates/steps/copy-dlls-for-test-step.yml@self | ||
| parameters: | ||
| softwareFolder: '${{ parameters.softwareFolder }}' | ||
| symbolsFolder: '${{ parameters.symbolsFolder }}' |
There was a problem hiding this comment.
The step at line 113 includes a comment "Copy DLLs and PDBs to the software and symbols folders for APIScan and testing." but the template invocation doesn't show any actual copy operations visible in this diff. Verify that the compound-step template at copy-dlls-for-test-step.yml actually performs the copy operations needed for APIScan and that the softwareFolder and symbolsFolder parameters are correctly wired through.
| @@ -43,8 +49,9 @@ steps: | |||
| Pattern: '${{ parameters.pattern }}' | |||
There was a problem hiding this comment.
The ESRP task versions were upgraded from v5 to v6 (EsrpMalwareScanning@6 and EsrpCodeSigning@6). Ensure that the new task versions are compatible with the current OneBranch pipeline configuration and that all required parameters are still supported. Review the breaking changes documentation for ESRP v5→v6 migration.
| - job: build_package_SqlClient | ||
| displayName: 'Build Microsoft.Data.SqlClient' |
There was a problem hiding this comment.
The job name changed from build_signed_package to build_package_SqlClient, but validate-signed-package-job.yml references the old job name via stageDependencies.build_dependent.build_package_SqlClient. However, the stage name appears to be buildMDS in the old code (line 35 shows the old reference). Verify that the stage name has also been updated to build_dependent in the calling pipeline, otherwise this job dependency will fail at runtime.
- Replaced copy scripts with CopyFiles@2 tasks.
mdaigle
left a comment
There was a problem hiding this comment.
It may work as a whole, but this is a tough one to review because there are so many ideas combined into one changeset. I'd really like to see pieces broken out so that they can be effectively reviewed.
| - task: DownloadPipelineArtifact@2 | ||
| displayName: 'Download Abstractions Package' | ||
| inputs: | ||
| artifactName: drop_build_independent_build_package_Abstractions |
There was a problem hiding this comment.
Probably best to have these come in as parameters. We don't have control over this artifact name and it could change in the future. The package step for the independent packages should output these values and then the pipeline should pass them in to this step. The ci-build-nugets-job.yml file is already doing this.
| type: string | ||
| default: MSSQLSERVER | ||
|
|
||
| # User. |
There was a problem hiding this comment.
None of these comments are really adding any value and they're greatly expanding the diff.
| parameters: | ||
| debug: ${{ parameters.debug }} | ||
|
|
||
| # We use the 'custom' command because the DotNetCoreCLI@2 task doesn't |
There was a problem hiding this comment.
I'm a little suspicious of this. It's a big pain to maintain multi-step builds all over the place. All of these supporting packages, should be buildable with a single dotnet pack command.
| value: >- | ||
| $(commonArguments) | ||
| --configuration ${{ parameters.buildConfiguration }} | ||
| -p:LoggingPackageVersion=${{ parameters.loggingPackageVersion }} |
There was a problem hiding this comment.
✏️ I think all of these package jobs could be factored out into a generic package job that takes package and assembly file version numbers as params. We could avoid a ton of extra stage and job files.
There was a problem hiding this comment.
Should move to src folder like other readmes
There was a problem hiding this comment.
should move to src folder with other readmes
- Fixed inconsistent/inaccurate official pipeline variable names.
Summary
Moves the ETW
SqlClientEventSourcetracing infrastructure (~1,180 lines) from the core driver into a newMicrosoft.Data.SqlClient.Extensions.Logging(netstandard2.0) NuGet package. This enables independent versioning and shared use across SqlClient and the AKV provider (which had its ownAKVEventSource, now deleted).Key Changes
Microsoft.Data.SqlClient.Extensions.Logging— containsSqlClientEventSource,SqlClientMetrics,SqlClientEventScope, and scope typesSqlClientEventSource.csreduced to a ~43-lineSqlClientDiagnosticsbridge; 28 source files updated fromTryEventScope/TrySNIEventScope→SqlClientEventScopeAKVEventSource.cs; AKV now uses the sharedSqlClientEventSource.Logfrom the Logging packagebuild.projgains Logging targets; nuspec files add Logging dependency across all TFMsPackageReadme.mdfor all 6 packages; new OneBranch pipeline design spec (522 lines); updatedAGENTS.mdChecklist