Conversation
…blish-symbols-step.
benrr101
added
the
Common Project 🚮
There was a problem hiding this comment.
Pull request overview
Updates OneBranch official/non-official pipeline templates to build Microsoft.Data.SqlClient (MDS) from build2.proj (common project) and refactors pipeline steps by removing the prior “compound-*” templates in favor of more granular build/sign/pack/analyze steps.
Changes:
- Replace the old SqlClient official build job with a new
build-signed-mds-package-job.ymlthat drives MDS build/pack viabuild2.proj. - Add new OneBranch step templates for Roslyn analyzers, MDS build/pack, ESRP signing, APIScan file extraction, and symbols publishing parameterization.
- Remove deprecated “compound-*” step templates and the prior SqlClient job template.
Reviewed changes
Copilot reviewed 17 out of 20 changed files in this pull request and generated 10 comments.
Show a summary per file
| File | Description |
|---|---|
| src/Microsoft.Data.SqlClient.sln | Updates solution items to reference new OneBranch job/step templates. |
| eng/pipelines/onebranch/variables/common-variables.yml | Updates comments around template aliases. |
| eng/pipelines/onebranch/stages/build-stages.yml | Switches SqlClient build job to new MDS/build2-based job and wires new parameters. |
| eng/pipelines/onebranch/jobs/build-signed-mds-package-job.yml | New job orchestrating build2-based MDS build/analyze/sign/pack/publish-symbols. |
| eng/pipelines/onebranch/jobs/build-signed-csproj-package-job.yml | Migrates to new Roslyn analyzers/sign/pack/symbol templates. |
| eng/pipelines/onebranch/steps/build-mds-step.yml | New step template to run build2.proj -t:BuildMds. |
| eng/pipelines/onebranch/steps/pack-mds-step.yml | New step template to run build2.proj -t:PackMds. |
| eng/pipelines/onebranch/steps/extract-apiscan-files-mds-step.yml | New step template to copy MDS DLL/PDB outputs to APIScan folders. |
| eng/pipelines/onebranch/steps/roslyn-analyzers-mds-step.yml | New step template to run Roslyn analyzers for build2-based MDS build. |
| eng/pipelines/onebranch/steps/roslyn-analyzers-csproj-step.yml | New generic Roslyn analyzers step for build.proj-driven builds. |
| eng/pipelines/onebranch/steps/publish-symbols-step.yml | Refactors the symbols publish template parameter model and implementation. |
| eng/pipelines/onebranch/steps/esrp-dll-signing-step.yml | Updates ESRP DLL signing inputs/paths and parameter quoting. |
| eng/pipelines/onebranch/steps/esrp-nuget-signing-step.yml | New dedicated ESRP NuGet signing step template. |
| eng/pipelines/onebranch/steps/pack-csproj-step.yml | New dedicated pack step for csproj-based extension packages. |
| eng/pipelines/onebranch/steps/build-csproj-step.yml | Comment update to reference new pack step template name. |
| eng/pipelines/onebranch/steps/esrp-code-signing-step.yml | Removed legacy combined DLL/pkg signing template. |
| eng/pipelines/onebranch/steps/compound-publish-symbols-step.yml | Removed deprecated compound symbols template. |
| eng/pipelines/onebranch/steps/compound-nuget-pack-step.yml | Removed deprecated compound NuGet pack template. |
| eng/pipelines/onebranch/steps/build-all-configurations-signed-dlls-step.yml | Removed legacy MDS build-all-configurations step driven by build.proj. |
| eng/pipelines/onebranch/jobs/build-signed-sqlclient-package-job.yml | Removed prior SqlClient official build job template. |
| msbuildArguments: >- | ||
| -t:PackMds | ||
| -p:PackBuild=false | ||
| -p:PackageVersionAbstraction="${{ parameters.abstractionsPackageVersion }}" |
There was a problem hiding this comment.
build2.proj expects the property PackageVersionAbstractions (plural). Using PackageVersionAbstraction here means PackMds will see the version as unset and fail with PackageVersionAbstractions must be set!.
| -p:PackageVersionAbstraction="${{ parameters.abstractionsPackageVersion }}" | |
| -p:PackageVersionAbstractions="${{ parameters.abstractionsPackageVersion }}" |
| -p:PackageVersionLogging="${{ parameters.loggingPackageVersion }}" | ||
| -p:PackageVersionMds="${{ parameters.mdsPackageVersion }}" | ||
| -p:ReferenceType=Package | ||
|
|
There was a problem hiding this comment.
This step runs PackMds but doesn't redirect the output directory to $(PACK_OUTPUT). By default, build2.proj packs into artifacts/Microsoft.Data.SqlClient/<ReferenceType>-<Configuration>, while esrp-nuget-signing-step.yml later signs $(PACK_OUTPUT) and the validation job verifies *.nupkg at the artifact root. Ensure the produced .nupkg/.snupkg end up in $(PACK_OUTPUT) (e.g., override the pack output property or copy the packages) so signing/validation/release can find them.
| - powershell: | | |
| $packOutput = "$(PACK_OUTPUT)" | |
| if (-not (Test-Path -LiteralPath $packOutput)) { | |
| New-Item -ItemType Directory -Path $packOutput | Out-Null | |
| } | |
| $artifactsRoot = "$(REPO_ROOT)\artifacts" | |
| if (Test-Path -LiteralPath $artifactsRoot) { | |
| Get-ChildItem -Path $artifactsRoot -Recurse -Include *.nupkg,*.snupkg | ForEach-Object { | |
| Copy-Item -LiteralPath $_.FullName -Destination $packOutput -Force | |
| } | |
| } | |
| displayName: 'Copy MDS packages to PACK_OUTPUT' |
There was a problem hiding this comment.
Not true, the mds job defines ob_outputDirectory as $(BUILD_OUTPUT), so BUILD_OUTPUT will be where artifacts are published from.
| # SqlServer, and SqlClient. | ||
| apiScanDllPath: '$(REPO_ROOT)/apiScan/Microsoft.Data.SqlClient/dlls' | ||
| apiScanPdbPath: '$(REPO_ROOT)/apiScan/Microsoft.Data.SqlClient/pdbs' | ||
| publishSymbols: '${{ parameters.publishSymbols }}' |
There was a problem hiding this comment.
publishSymbols is a boolean parameter in build-signed-mds-package-job.yml, but it's being passed as a quoted string here. Template boolean parameters require the unquoted boolean expression; keep this as ${{ parameters.publishSymbols }} so the if parameters.publishSymbols condition works as intended.
| publishSymbols: '${{ parameters.publishSymbols }}' | |
| publishSymbols: ${{ parameters.publishSymbols }} |
There was a problem hiding this comment.
No quoted strings required here.
| - template: /eng/pipelines/onebranch/jobs/build-signed-mds-package-job.yml@self | ||
| parameters: | ||
| publishSymbols: ${{ parameters.publishSymbols }} | ||
| isPreview: ${{ parameters.isPreview }} | ||
| # TODO: This job should use the effective versions for Abstractions, Logging, | ||
| # SqlServer, and SqlClient. | ||
| apiScanDllPath: '$(REPO_ROOT)/apiScan/Microsoft.Data.SqlClient/dlls' | ||
| apiScanPdbPath: '$(REPO_ROOT)/apiScan/Microsoft.Data.SqlClient/pdbs' | ||
| publishSymbols: '${{ parameters.publishSymbols }}' | ||
| signingAppRegistrationClientId: '$(AppRegistrationClientId)' | ||
| signingAppRegistrationTenantId: '$(AppRegistrationTenantId)' | ||
| signingAuthAkvName: '$(AuthAKVName)' | ||
| signingAuthSignCertName: '$(AuthSignCertName)' | ||
| signingEsrpClientId: '$(ESRPClientId)' | ||
| signingEsrpConnectedServiceName: '$(ESRPConnectedServiceName)' | ||
| symbolsAzureSubscription: 'Symbols publishing Workload Identity federation service-ADO.Net' | ||
| symbolsPublishProjectName: 'Microsoft.Data.SqlClient.SNI' | ||
| symbolsPublishServer: '$(SymbolServer)' | ||
| symbolsPublishTokenUri: '$(SymbolTokenUri)' | ||
| symbolsUploadAccount: 'SqlClientDrivers' | ||
|
|
||
| abstractionsArtifactName: '$(abstractionsArtifactsName)' | ||
| abstractionsPackageVersion: '$(effectiveAbstractionsVersion)' | ||
| loggingArtifactName: '$(loggingArtifactsName)' | ||
| loggingPackageVersion: '$(effectiveLoggingVersion)' | ||
| mdsPackageVersion: '$(effectiveSqlClientVersion)' | ||
|
|
There was a problem hiding this comment.
Switching the SqlClient build from build-signed-sqlclient-package-job.yml to build-signed-mds-package-job.yml changes the job name (now buildSignedMdsPackage), which changes the OneBranch auto-published artifact name (drop_<stage>_<job>). Downstream steps in this pipeline still reference $(sqlClientArtifactsName) (currently drop_build_dependent_build_package_SqlClient) for validation and AKV provider dependencies; update the artifact name mapping (and/or the new job name) so those downloads keep working.
| projectName: '$(PACKAGE_NAME)' | ||
| publishProjectName: '${{ parameters.symbolsPublishProjectName }}' | ||
| publishServer: '${{ parameters.symbolsPublishServer }}' | ||
| publishToInternal: true | ||
| publishToPublic: true | ||
| publishTokenUri: '${{ parameters.symbolsPublishTokenUri }}' | ||
| referenceType: Package |
There was a problem hiding this comment.
The publish-symbols-step.yml template parameters are packageName and do not include projectName or referenceType. As written, this invocation will fail template validation. Rename projectName to packageName (and drop referenceType) to match the new template’s parameter list.
| projectName: '$(PACKAGE_NAME)' | |
| publishProjectName: '${{ parameters.symbolsPublishProjectName }}' | |
| publishServer: '${{ parameters.symbolsPublishServer }}' | |
| publishToInternal: true | |
| publishToPublic: true | |
| publishTokenUri: '${{ parameters.symbolsPublishTokenUri }}' | |
| referenceType: Package | |
| packageName: '$(PACKAGE_NAME)' | |
| publishProjectName: '${{ parameters.symbolsPublishProjectName }}' | |
| publishServer: '${{ parameters.symbolsPublishServer }}' | |
| publishToInternal: true | |
| publishToPublic: true | |
| publishTokenUri: '${{ parameters.symbolsPublishTokenUri }}' |
| publishToInternal: 'true' | ||
| publishToPublic: 'true' |
There was a problem hiding this comment.
publishToInternal / publishToPublic are declared as boolean parameters in publish-symbols-step.yml, but this job passes them as quoted strings. This can break template type checking and conditionals; pass boolean literals (true/false) instead.
| publishToInternal: 'true' | |
| publishToPublic: 'true' | |
| publishToInternal: true | |
| publishToPublic: true |
There was a problem hiding this comment.
Agreed - we should only quote YAML strings when necessary, like when a string starts with *. So none of these new parameters need to be quoted except searchPattern.
There was a problem hiding this comment.
I don't know ... I don't have a good enough argument for or against it. Wrapping everything in quotes just seemed safer.
| # Aliases required by compound step templates (compound-esrp-dll-signing-step, | ||
| # compound-esrp-nuget-signing-step, compound-nuget-pack-step, etc.). | ||
| # Aliases required by OneBranch step templates (esrp-dll-signing-step, | ||
| # esrp-nuget-signing-step, nuget-pack-step, etc.). |
There was a problem hiding this comment.
The header comment mentions nuget-pack-step, but there is no such OneBranch step template under eng/pipelines/onebranch/steps/ (the PR adds pack-csproj-step.yml and pack-mds-step.yml instead). Update the comment to reference the actual templates to avoid confusion for future pipeline edits.
| # esrp-nuget-signing-step, nuget-pack-step, etc.). | |
| # esrp-nuget-signing-step, pack-csproj-step, pack-mds-step, etc.). |
| parameters: | ||
| # Path where dll files should be copied to for APIScan | ||
| - name: dllpath | ||
| type: string | ||
|
|
||
| # Path where pdb files should be copied to for APIScan | ||
| - name: pdbPath | ||
| type: string | ||
|
|
||
| - name: referenceType | ||
| type: string | ||
| values: | ||
| - Package | ||
| - Project | ||
|
|
||
| steps: | ||
| - task: CopyFiles@2 | ||
| displayName: 'Copy DLLs for APIScan' | ||
| inputs: | ||
| contents: '**/Microsoft.Data.SqlClient.dll' | ||
| flattenFolders: false # Disabled to keep different frameworks and OS builds separate in the target | ||
| sourceFolder: '$(BUILD_OUTPUT)/Microsoft.Data.SqlClient/${{ parameters.referenceType }}-Release/' | ||
| targetFolder: '${{ parameters.dllPath }}/' | ||
|
|
There was a problem hiding this comment.
In this template, the parameter is declared as dllpath but referenced as parameters.dllPath later. Azure Pipelines template parameters are case-sensitive, so this will fail template expansion. Rename the parameter to dllPath (or update the references) so the declaration and usages match.
There was a problem hiding this comment.
No, they're not case-sensitive, but I agree we should use consistent casing.
| type: windows | ||
|
|
||
| variables: | ||
| ob_outputDirectory: '$(BUILD_OUTPUT)' |
There was a problem hiding this comment.
ob_outputDirectory is set to $(BUILD_OUTPUT) (the repo-wide artifacts/ root). The validation/release flows expect the SqlClient .nupkg/.snupkg to be available directly under the downloaded artifact root (e.g., nuget verify $(path)\*.nupkg in validate-signed-package-job.yml). With the current setup, the packages are likely nested under artifacts/Microsoft.Data.SqlClient/... and won't be found. Consider publishing $(PACK_OUTPUT) (or copying packages to the artifact root) to keep downstream validation/release jobs working.
| ob_outputDirectory: '$(BUILD_OUTPUT)' | |
| ob_outputDirectory: '$(PACK_OUTPUT)' |
There was a problem hiding this comment.
They should still be found because the validation step should be pulling down the artifacts from the previous stages/jobs before doing validation.
| # See the LICENSE file in the project root for more information. # | ||
| ################################################################################# | ||
|
|
||
| # This template defines a step to run Roslyn Analyzers on the AKV project build. It uses the |
There was a problem hiding this comment.
This file runs Roslyn analyzers for the MDS build (build2.proj -t:BuildMds), but the comment says “AKV project build”. Update the comment to reflect MDS so the template isn’t misleading.
| # This template defines a step to run Roslyn Analyzers on the AKV project build. It uses the | |
| # This template defines a step to run Roslyn Analyzers on the MDS build. It uses the |
| # # | ||
| # doc: https://www.osgwiki.com/wiki/Symbols_Publishing_Pipeline_to_SymWeb_and_MSDL # | ||
| #################################################################################### | ||
| ################################################################################# |
There was a problem hiding this comment.
This file's diff looks funky, that's just because I did these steps:
- Delete
publish-symbols-step.yml - Rename
compound-publish-symbols-step.ymltopublish-symbols-step.yml
Codecov Report✅ All modified and coverable lines are covered by tests.
Additional details and impacted files@@ Coverage Diff @@
## main #4068 +/- ##
==========================================
- Coverage 75.15% 65.62% -9.54%
==========================================
Files 280 275 -5
Lines 43830 65825 +21995
==========================================
+ Hits 32940 43197 +10257
- Misses 10890 22628 +11738
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:
|
| artifactName: '${{ parameters.packageFullName }}_symbols_$(System.TeamProject)_$(Build.Repository.Name)_$(Build.SourceBranchName)_${{ parameters.packageVersion }}_$(System.TimelineId)' | ||
| azureSubscription: 'Symbols publishing Workload Identity federation service-ADO.Net' | ||
| packageName: '${{ parameters.packageFullName }}' | ||
| publishProjectName: 'Microsoft.Data.SqlClient.SNI' |
There was a problem hiding this comment.
That doesn't seem like the correct project name, but it is what the old code was using. Are we sure about this?
There was a problem hiding this comment.
Yes, I've asked about this in the past and it seems to be correct. I in fact argued about this for quite a while about how we should have different symbols publishing libraries per project, but I was told that this will never be the case.
There was a problem hiding this comment.
It may make more sense then to leave it hard coded in the task. If not, we should at least add a comment explaining this. I could see myself easily changing this thinking it was set mistakenly.
| # SqlServer, and SqlClient. | ||
| apiScanDllPath: '$(REPO_ROOT)/apiScan/Microsoft.Data.SqlClient/dlls' | ||
| apiScanPdbPath: '$(REPO_ROOT)/apiScan/Microsoft.Data.SqlClient/pdbs' | ||
| publishSymbols: '${{ parameters.publishSymbols }}' |
There was a problem hiding this comment.
No quoted strings required here.
There was a problem hiding this comment.
This seems like an unnecessary level of abstraction. This file is only used in one place so its steps could be inlined in the calling job.
I see other existing steps like this as well, so let's re-visit after all of the build2.proj work is done.
There was a problem hiding this comment.
Oh, maybe. But the csproj version does the same thing, and I think I was following a pattern from earlier when I built the AKV pipeline that I modeled this one after.
| parameters: | ||
| # Path where dll files should be copied to for APIScan | ||
| - name: dllpath | ||
| type: string | ||
|
|
||
| # Path where pdb files should be copied to for APIScan | ||
| - name: pdbPath | ||
| type: string | ||
|
|
||
| - name: referenceType | ||
| type: string | ||
| values: | ||
| - Package | ||
| - Project | ||
|
|
||
| steps: | ||
| - task: CopyFiles@2 | ||
| displayName: 'Copy DLLs for APIScan' | ||
| inputs: | ||
| contents: '**/Microsoft.Data.SqlClient.dll' | ||
| flattenFolders: false # Disabled to keep different frameworks and OS builds separate in the target | ||
| sourceFolder: '$(BUILD_OUTPUT)/Microsoft.Data.SqlClient/${{ parameters.referenceType }}-Release/' | ||
| targetFolder: '${{ parameters.dllPath }}/' | ||
|
|
There was a problem hiding this comment.
No, they're not case-sensitive, but I agree we should use consistent casing.
There was a problem hiding this comment.
We're copying, not extracting. Maybe copy-files-for-apiscan ?
There was a problem hiding this comment.
I saw it as "extract them from the complete build output" not like uncompress "extract". Copy works too.
github-project-automation
bot
moved this from In review
to In progress
in SqlClient Board
mdaigle
left a comment
mdaigle
left a comment
There was a problem hiding this comment.
Really just the one comment, otherwise looks good. I would also like to review the pipeline run when we get one that's green.
| artifactName: '${{ parameters.packageFullName }}_symbols_$(System.TeamProject)_$(Build.Repository.Name)_$(Build.SourceBranchName)_${{ parameters.packageVersion }}_$(System.TimelineId)' | ||
| azureSubscription: 'Symbols publishing Workload Identity federation service-ADO.Net' | ||
| packageName: '${{ parameters.packageFullName }}' | ||
| publishProjectName: 'Microsoft.Data.SqlClient.SNI' |
There was a problem hiding this comment.
It may make more sense then to leave it hard coded in the task. If not, we should at least add a comment explaining this. I could see myself easily changing this thinking it was set mistakenly.
mdaigle
left a comment
mdaigle
left a comment
There was a problem hiding this comment.
Really just the one comment, otherwise looks good. I would also like to review the pipeline run when we get one that's green.
There was a problem hiding this comment.
🤖
Code Review Summary
Thanks for moving the MDS build to build2.proj — the cleanup of the "compound-" prefix and the separation of MDS into its own job/step templates is a nice improvement.
I found 3 critical issues and 1 major issue that will likely cause the official pipeline to produce incorrectly signed or broken packages:
Critical
| # | Issue | File |
|---|---|---|
| C1 | Typo: PackageVersionAbstraction → PackageVersionAbstractions (missing trailing 's') — pack step will fail |
pack-mds-step.yml:27 |
| C2 | ESRP NuGet signing scans wrong directory: Signing searches $(PACK_OUTPUT) (output/) but PackMds emits .nupkg to $(BUILD_OUTPUT)/Microsoft.Data.SqlClient/Package-Release/ — packages ship unsigned |
build-signed-mds-package-job.yml:142 |
| C3 | PackMds re-builds over signed DLLs: DependsOnTargets="BuildMds" re-triggers the build in a fresh MSBuild invocation, overwriting ESRP-signed DLLs. -p:PackBuild=false has no effect (not implemented in build2.proj) |
pack-mds-step.yml:25 |
Major
| # | Issue | File |
|---|---|---|
| M1 | $(PACKAGE_NAME) is undefined: Symbols publish with empty product name |
build-signed-mds-package-job.yml:157 |
Minor (not commented inline)
- Missing
@selfonpack-mds-step.ymltemplate reference (line 139 of the job file) ob_outputDirectory: '$(BUILD_OUTPUT)'publishes the entireartifacts/tree instead of just nupkg — compare with csproj jobs which use$(PACK_OUTPUT)
Question
Has the test build (pipeline 144204) successfully produced and validated a signed MDS package? The issues above should cause failures in the signing/validation stages.
| msbuildArguments: >- | ||
| -t:PackMds | ||
| -p:PackBuild=false | ||
| -p:PackageVersionAbstractions="${{ parameters.abstractionsPackageVersion }}" |
There was a problem hiding this comment.
Critical: Typo — PackageVersionAbstraction should be PackageVersionAbstractions
The MSBuild property in build2.proj is PackageVersionAbstractions (with trailing s). This typo means the PackMds target will see PackageVersionAbstractions as empty and will fail with:
Error: PackageVersionAbstractions must be set!
The build step (build-mds-step.yml) uses the correct spelling (PackageVersionAbstractions), so only the pack step is affected.
Fix: Change -p:PackageVersionAbstraction= to -p:PackageVersionAbstractions=
| abstractionsPackageVersion: '${{ parameters.abstractionsPackageVersion }}' | ||
| loggingPackageVersion: '${{ parameters.loggingPackageVersion }}' | ||
| mdsPackageVersion: '${{ parameters.mdsPackageVersion }}' | ||
|
|
There was a problem hiding this comment.
Critical: ESRP NuGet signing will not find any packages
The esrp-nuget-signing-step.yml scans $(PACK_OUTPUT) (= $(REPO_ROOT)/output) for *.*nupkg. However, the PackMds target in build2.proj outputs packages to:
$(MdsArtifactRoot)/$(ReferenceType)-$(Configuration)
= artifacts/Microsoft.Data.SqlClient/Package-Release/
This is under $(BUILD_OUTPUT) (artifacts/), not $(PACK_OUTPUT) (output/). The ESRP NuGet signing step will find zero packages and exit silently, resulting in unsigned NuGet packages being published as the pipeline artifact.
Fix options:
- Add a step before NuGet signing to copy the
.nupkg/.snupkgfromartifacts/Microsoft.Data.SqlClient/Package-Release/to$(PACK_OUTPUT), or - Modify the
PackMdstarget to output directly to$(PACK_OUTPUT)by passing-p:MdsArtifactRoot=$(PACK_OUTPUT)or an equivalent override
| solution: '$(REPO_ROOT)/build2.proj' | ||
| configuration: 'Release' | ||
| msbuildArguments: >- | ||
| -t:PackMds |
There was a problem hiding this comment.
Critical: PackMds will re-trigger BuildMds, overwriting ESRP-signed DLLs
The pipeline flow is: Build → ESRP DLL Sign → Pack → ESRP NuGet Sign.
However, PackMds in build2.proj has DependsOnTargets="BuildMds". Since the build step and pack step are separate MSBuild@1 task invocations, MSBuild's "run each target once" guarantee does not carry across invocations. When PackMds runs, it triggers BuildMds again, which overwrites the ESRP-signed DLLs with freshly-compiled unsigned ones. The unsigned DLLs then get packaged.
The -p:PackBuild=false property is passed here but is never checked anywhere in build2.proj — it has no effect.
Fix options:
- Add a condition to
build2.projso thatPackMdsskips itsDependsOnTargetswhenPackBuild=false:Or more simply, make<Target Name="PackMdsOnly" Condition="'$(PackBuild)' == 'false'"> ... </Target> <Target Name="PackMds" DependsOnTargets="BuildMds" Condition="'$(PackBuild)' != 'false'"> ... </Target>
DependsOnTargetsconditional. - Create a separate
PackMdsNoBuildtarget that only contains the packaging logic.
| - template: /eng/pipelines/onebranch/steps/publish-symbols-step.yml@self | ||
| parameters: | ||
| artifactName: 'Microsoft.Data.SqlClient_symbols_$(System.TeamProject)_$(Build.Repository.Name)_$(Build.SourceBranchName)_${{ parameters.mdsPackageVersion }}_$(System.TimelineId)' | ||
| azureSubscription: '${{ parameters.symbolsAzureSubscription }}' |
There was a problem hiding this comment.
Major: $(PACKAGE_NAME) is undefined — symbols will publish with an empty product name
The packageName parameter receives $(PACKAGE_NAME), but this variable is not defined in the job's variables block, in common-variables.yml, or in onebranch-variables.yml. It will resolve to an empty string at runtime, causing SymbolsProduct to be blank in the PublishSymbols@2 task.
Fix: Replace $(PACKAGE_NAME) with a literal value:
packageName: 'Microsoft.Data.SqlClient'
Description
This PR is the last functional PR for common project completion. It updates the official/non-official builds to use the targets from build2.proj, and effectively build the common project for official releases. I had plans for a larger overhaul of the "new" official pipeline, but I lost control of the direction, so I took a step back, pulled out the minimal changes to make this happen and am submitting this now.
Since the
*csproj*steps/jobs are based on build.proj, I've created separate steps for MDS build.🤖
Dropped "compound-" from steps files and fixed links. I thought I was onto something when I adopted that naming convention a while back, but ... no.
Issues
N/A
Testing
Currently running test build can he found: https://sqlclientdrivers.visualstudio.com/ADO.Net/_build/results?buildId=144204&view=results