Trigger Kerberos CI from package pipeline - #4499
Conversation
There was a problem hiding this comment.
Pull request overview
Updates the Kerberos CI Azure Pipelines YAML to use the package-triggered pipeline model (introduced in #4482), aligning source to the upstream package commit while keeping eng/pipelines pinned to the queued commit so runtime scripts match compiled YAML.
Changes:
- Switched Kerberos CI from a daily schedule to a pipeline-completion trigger on
sqlclient-ci-package. - Enhanced the shared source-alignment step to persist checkout credentials and explicitly fetch the upstream SHA before checkout.
- Added a validated
dotnetVerbosityparameter and threaded it through Kerberos build/test steps.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| eng/pipelines/common/steps/align-source-with-upstream-step.yml | Persists credentials and fetches the upstream commit SHA to make source alignment resilient. |
| eng/pipelines/ci/kerberos/sqlclient-ci-kerberos-pipeline.yml | Replaces schedule with pipeline completion trigger and adopts the shared source-alignment template; adds dotnetVerbosity pipeline parameter. |
| eng/pipelines/ci/kerberos/build-and-test-steps.yml | Adds a dotnetVerbosity template parameter and applies it to all dotnet build invocations. |
765ca3d to
9e92e24
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.
Suppressed comments (1)
eng/pipelines/common/steps/align-source-with-upstream-step.yml:51
- The upstream commit SHA comes from a pipeline resource variable and is passed directly into
git fetch/git checkout. Even though it should be a 40-hex SHA, validating it defensively avoids accidental malformed values (or argument injection if the variable were ever unexpected) causing the fetch/checkout to behave incorrectly.
$sha = "$(resources.pipeline.${{ parameters.upstreamPipeline }}.sourceCommit)"
$pipelineSourceSha = git rev-parse HEAD
if ($LASTEXITCODE -ne 0) { throw "Failed to resolve the queued pipeline commit." }
Write-Host "Fetching ${{ parameters.upstreamPipeline }} commit $sha"
git fetch --no-tags origin $sha
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 13 out of 13 changed files in this pull request and generated 2 comments.
Suppressed comments (6)
eng/pipelines/ci/managed-instance/sqlclient-ci-managed-instance-stages.yml:70
- This stage pins the Windows vmImage to
ADO-Win25. If that value isn’t a validimageOverridecapability in Managed-Instance-pool, the job will be stuck waiting for an agent. Consider using the standard Windows SQL 2022 image used across other pipelines.
runtime: ${{ runtime }}
useManagedSNI: false
vmImage: ADO-Win25
eng/pipelines/ci/managed-instance/sqlclient-ci-managed-instance-stages.yml:100
- The Linux vmImage is set to
ADO-UB24, which isn’t referenced anywhere else in the repo’s pipeline image lists (commonlyADO-UB22-SQL22). If Managed-Instance-pool doesn’t have an agent withimageOverride=ADO-UB24, these jobs will not start.
operatingSystem: Linux
runtime: ${{ runtime }}
vmImage: ADO-UB24
eng/pipelines/ci/managed-instance/sqlclient-ci-managed-instance-stages.yml:82
- This stage pins the Windows vmImage to
ADO-Win25, which is inconsistent with the repo’s typical Windows image naming (e.g.,ADO-MMS22-SQL22). If Managed-Instance-pool doesn’t provide this imageOverride value, the managed-SNI leg will not run.
runtime: ${{ runtime }}
useManagedSNI: true
vmImage: ADO-Win25
eng/pipelines/ci/kerberos/sqlclient-ci-kerberos-stages.yml:73
- This Windows Kerberos job also demands
ImageOverride=ADO-Win25. If that capability isn’t available in the ADO-Trusted-Domain-Win-WestUS2 pool, this leg won’t get an agent. Consider using the same established image name as other Windows runs.
poolName: ADO-Trusted-Domain-Win-WestUS2
runtime: ${{ runtime }}
useManagedSNI: false
vmImage: ADO-Win25
eng/pipelines/ci/kerberos/sqlclient-ci-kerberos-stages.yml:86
- This managed-SNI Windows Kerberos job also demands
ImageOverride=ADO-Win25. If that imageOverride value isn’t present in the pool capabilities, the managed-SNI legs will never run.
poolName: ADO-Trusted-Domain-Win-WestUS2
runtime: ${{ runtime }}
useManagedSNI: true
vmImage: ADO-Win25
eng/pipelines/ci/kerberos/sqlclient-ci-kerberos-stages.yml:107
- The Linux Kerberos jobs demand
ImageOverride=ADO-UB24. The repo’s other Linux jobs typically useADO-UB20-SQL22/ADO-UB22-SQL22; if this pool doesn’t provideADO-UB24, these jobs will stay queued.
poolName: ADO-Trusted-Linux-WestUS2
runtime: ${{ runtime }}
vmImage: ADO-UB24
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev/paul/sqlclient-ci-managed-instance #4499 +/- ##
==========================================================================
- Coverage 62.81% 62.72% -0.09%
==========================================================================
Files 283 283
Lines 66979 66979
==========================================================================
- Hits 42073 42015 -58
- Misses 24906 24964 +58
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
This should appear as a rename+edit from linux-init-step.yml, but alas appears as a new file.
| -t:TestSqlClientManual | ||
| -p:TestFramework=${{ parameters.runtime }} | ||
| -p:TestSet=3 | ||
| -p:TestFilters="category!=failing&category!=flaky&category!=interactive&(FullyQualifiedName~KerberosTests|FullyQualifiedName~IntegratedAuthenticationTest|FullyQualifiedName~InstanceNameTest)" |
There was a problem hiding this comment.
This is an aggressive filter. Kerberos is an authentication mechanism, so the theory is that post-login, there isn't much worth testing. Other pipelines will run the larger integration suite against a wide variety of SQL Server types and versions. @David-Engel - Looking for your thoughts here.
| # branch for manual and scheduled builds" definition. Because both pipelines use the same | ||
| # repository, an eligible run executes this YAML from the triggering package run's branch and | ||
| # commit, preserving branch-specific pipeline definitions. | ||
| resources: |
There was a problem hiding this comment.
We're now triggering on completion of the upstream sqlclient-ci-package pipeine - no more scheduled runs.
| - template: /eng/pipelines/common/templates/jobs/ci-code-coverage-job.yml@self | ||
| parameters: | ||
| upload: false | ||
| - template: /eng/pipelines/ci/kerberos/sqlclient-ci-kerberos-stages.yml@self |
There was a problem hiding this comment.
The remaining changes here are re-modelling the pipeline to have the same layout as Managed Instance. We will endeavour to keep these new CI test pipelines looking and feeling similar.
There was a problem hiding this comment.
This is another rename+edit that isn't being treated properly.
| $sha = "$(resources.pipeline.${{ parameters.upstreamPipeline }}.sourceCommit)" | ||
| $pipelineSourceSha = git rev-parse HEAD | ||
| if ($LASTEXITCODE -ne 0) { throw "Failed to resolve the queued pipeline commit." } | ||
| Write-Host "Fetching ${{ parameters.upstreamPipeline }} commit $sha" |
There was a problem hiding this comment.
This ensures that $sha is available to be checked-out below.
| DOMAIN="${{ parameters.kerberosDomain }}" | ||
| DOMAIN_OU="${{ parameters.kerberosDomainOU }}" | ||
| DOMAIN_USER="${{ parameters.kerberosDomainUser }}" | ||
| DOMAIN_PASSWORD="${{ parameters.kerberosDomainPassword }}" |
There was a problem hiding this comment.
Suggestion: pass the password through env: like the pwsh step above does, and read $DOMAIN_PASSWORD from the environment. Interpolating it into the script body means the expanded domain password lands in plaintext in the agent's _temp/*.sh file on a shared self-hosted agent.
| pipelines: | ||
| - pipeline: sqlclient-ci-package | ||
| source: sqlclient-ci-package | ||
| trigger: true |
There was a problem hiding this comment.
Suggestion: keep a low-frequency schedule on internal/main alongside the completion trigger. With the daily cron gone, Kerberos coverage stops with no signal if sqlclient-ci-package starts failing or the resource trigger gets misconfigured in the pipeline definition. A weekly always: true run gives a floor.
| condition: and(succeededOrFailed(), eq(variables['HasTestResultsDir'], 'true')) | ||
| inputs: | ||
| targetPath: $(Build.SourcesDirectory)/test_results | ||
| artifact: ${{ parameters.runtime }}-${{ lower(parameters.operatingSystem) }}-$(System.JobId) |
There was a problem hiding this comment.
The Windows artifact name dropped the SNI discriminator that the old matrix had (ManagedSNI_$(managedSNI)), so native and managed SNI runs for the same TFM are only distinguishable by JobId. Same for the coverage rename prefix on line 144. Suggestion: fold the SNI mode into both.
Description
Updates the Kerberos integration pipeline to consume and test the exact packages produced by
sqlclient-ci-package, and restructures the Kerberos and Managed Instance pipelines into explicit OS stages.Kerberos pipeline
sqlclient-ci-packagepipeline. Because both pipelines use the same repository, eligible runs use the triggering package run's branch and commit.eng/pipelinesfrom the commit that queued the downstream run. The shared alignment step now persists checkout credentials and fetches the upstream SHA so it also works when that commit is ahead of the queued commit.ReferenceType=Packageand the exact package versions instead of rebuilding SqlClient.KerberosTests,IntegratedAuthenticationTest, andInstanceNameTest, which exercise the configured Kerberos environment.net462native SNI plusnet8.0,net9.0, andnet10.0with native and managed SNI) and three Linux jobs (net8.0,net9.0, andnet10.0).dotnetVerbosityparameter through package-mode test commands.Related pipelines
sqlclient-ci-package.No product code, public API, documentation, or localization changes are included.
Testing