Skip to content

Fix forked repo local SQL Server passwords #3950

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.

Sign up for GitHub

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

Open
paulmedynski wants to merge 5 commits into
base: main
Choose a base branch
from
+626 −483
Open

Fix forked repo local SQL Server passwords #3950

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
aa1d590
Task 42348: Fix forked repo local SQL Server passwords
paulmedynski Feb 11, 2026
064e9af
Task 42348: Fix forked repo local SQL Server passwords
paulmedynski Feb 11, 2026
0948c0b
Forked Pipeline SA Password Test (#3952)
paulmedynski Feb 12, 2026
2fa86a0
Task 42348: Fix forked repo local SQL Server passwords
paulmedynski Feb 12, 2026
af6cfae
Task 42348: Fix forked repo local SQL Server passwords
paulmedynski Feb 12, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions eng/pipelines/common/templates/jobs/ci-run-tests-job.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -116,6 +116,10 @@ parameters:
type: boolean
default: false

# The SA password to set when configuring SQL Server.
- name: saPassword
Copy link
Contributor Author

@paulmedynski paulmedynski Feb 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I decided to plumb the SA password down to all of the steps that need it via parameters rather than using (global) variables. This is the approach we will be taking with the new pipelines.

type: string

jobs:
- job: ${{ format('{0}', coalesce(parameters.jobDisplayName, parameters.image, 'unknown_image')) }}

Expand Down Expand Up @@ -179,6 +183,7 @@ jobs:
- template: /eng/pipelines/common/templates/steps/update-config-file-step.yml@self # update config.json file
parameters:
debug: ${{ parameters.debug }}
saPassword: ${{ parameters.saPassword }}
UseManagedSNIOnWindows: ${{ parameters.usemanagedSNI }}
${{ if parameters.configProperties.TCPConnectionString }}:
TCPConnectionString: ${{ parameters.configProperties.TCPConnectionString }}
Expand Down Expand Up @@ -255,6 +260,7 @@ jobs:
parameters:
operatingSystem: ${{ parameters.operatingSystem }}
netcoreVersionTestUtils: ${{ parameters.netcoreVersionTestUtils }}
saPassword: ${{ parameters.saPassword }}
${{ if parameters.configProperties.instanceName }}:
instanceName: ${{ parameters.configProperties.instanceName }}
${{ if parameters.configProperties.user }}:
Expand Down
2 changes: 2 additions & 0 deletions eng/pipelines/common/templates/jobs/run-tests-package-reference-job.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -46,6 +46,8 @@ jobs:

- template: /eng/pipelines/common/templates/steps/update-config-file-step.yml
parameters:
# We use the Library $(Password) variable as the SA password in this pipeline.
saPassword: $(Password)
Copy link
Contributor Author

@paulmedynski paulmedynski Feb 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The ADO.Net pipelines never run against forks, so they always have access to the Library variables. I didn't convert this pipeline to use parameters instead of global variables - it wasn't worth it.

TCPConnectionString: $(SQL_TCP_CONN_STRING)
NPConnectionString: $(SQL_NP_CONN_STRING)
SupportsIntegratedSecurity: false
Expand Down
24 changes: 19 additions & 5 deletions eng/pipelines/common/templates/stages/ci-run-tests-stage.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,13 +3,20 @@
# The .NET Foundation licenses this file to you under the MIT license. #
# See the LICENSE file in the project root for more information. #
#################################################################################

# This stage depends on the secrets_stage.

parameters:
- name: abstractionsArtifactsName
type: string

- name: abstractionsPackageVersion
type: string

- name: additionalDependsOn
type: object
default: []

- name: buildConfiguration
type: string
values:
Expand All @@ -20,10 +27,6 @@ parameters:
type: boolean
default: false

- name: dependsOn
type: object
default: []

- name: mdsArtifactsName
type: string
default: MDS.Artifacts
Expand Down Expand Up @@ -56,7 +59,16 @@ stages:
- ${{ each config in parameters.testConfigurations }}:
- ${{ each image in config.value.images }}:
- stage: ${{ image.key }}
dependsOn: ${{ parameters.dependsOn }}
dependsOn:
- secrets_stage
- ${{ each dep in parameters.additionalDependsOn }}:
- ${{ dep }}

variables:
# Bring the SA password from the secrets_stage into scope here.
- name: saPassword
value: $[stageDependencies.secrets_stage.secrets_job.outputs['SaPassword.Value']]
Copy link
Contributor Author

@paulmedynski paulmedynski Feb 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the magic that fetches the SA password from the secrets_stage and expands it into a variable we can use as a parameter to the downstream jobs and steps.

This $[ ... ] syntax is not evaluated if used directly as a parameter value, so we must use this intermediate variable.


jobs:
- ${{ each targetFramework in config.value.TargetFrameworks }}:
- ${{ each platform in config.value.buildPlatforms }}:
Expand Down Expand Up @@ -87,6 +99,7 @@ stages:
configSqlFor: ${{ config.value.configSqlFor }}
operatingSystem: ${{ config.value.operatingSystem }}
isArm64: ${{ eq(config.value.isArm64, 'true') }}
saPassword: $(saPassword)
${{if ne(config.value.configProperties, '{}') }}:
${{ each x86TF in config.value.configProperties.x86TestTargetFrameworks }}:
${{ if eq(x86TF, targetFramework) }}:
Expand Down Expand Up @@ -123,6 +136,7 @@ stages:
configSqlFor: ${{ config.value.configSqlFor }}
operatingSystem: ${{ config.value.operatingSystem }}
isArm64: ${{ eq(config.value.isArm64, 'true') }}
saPassword: $(saPassword)
${{if and(eq(usemanagedSNI, false), ne(config.value.configProperties, '{}')) }}:
${{ each x86TF in config.value.configProperties.x86TestTargetFrameworks }}:
${{ if eq(x86TF, targetFramework) }}:
Expand Down
89 changes: 43 additions & 46 deletions eng/pipelines/common/templates/steps/configure-sql-server-linux-step.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,54 +7,51 @@
# This step configures an existing SQL Server running on the local Linux host. For example, our 1ES
# Hosted Pool has images like ADO-UB20-SQL22 that come with SQL Server 2022 pre-installed and
# running.
#
# The SA password is set to the value of the $(Password) variable defined in the ADO Library "ADO
# Test Configuration properties", brought in by common/templates/libraries/ci-build-variables.yml.

parameters:
- name: condition
Copy link
Contributor Author

@paulmedynski paulmedynski Feb 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These condition parameters were not being used. The OS-specific config templates were already being used only for the appropriate OS anyway.


# The SA password to set when configuring SQL Server.
- name: saPassword
type: string
default: and(succeeded(), eq(variables['Agent.OS'], 'Linux'))

steps:
# Linux only steps
- bash: |
sudo systemctl stop mssql-server
# Password for the SA user (required)
MSSQL_SA_PW="$(Password)"
# Product ID of the version of SQL server you're installing
# Must be evaluation, developer, express, web, standard, enterprise, or your 25 digit product key
MSSQL_PID="enterprise"
echo Running mssql-conf setup...
sudo MSSQL_SA_PASSWORD="$MSSQL_SA_PW" \
MSSQL_PID="$MSSQL_PID" \
/opt/mssql/bin/mssql-conf -n setup accept-eula
# Connect to server and get the version:
counter=1
errstatus=1
while [ $counter -le 5 ] && [ $errstatus = 1 ]
do
echo Waiting for SQL Server to start...
sleep 3s
/opt/mssql-tools/bin/sqlcmd \
-S localhost \
-U SA \
-P $MSSQL_SA_PW\
-Q "SELECT @@VERSION" 2>/dev/null
errstatus=$?
((counter++))
done
# Display error if connection failed:
if [ $errstatus = 1 ]
then
echo Cannot connect to SQL Server, installation aborted
exit $errstatus
fi
displayName: 'Configure SQL Server [Linux]'
condition: ${{parameters.condition }}

# Configure SQL Server.
- bash: |
sudo systemctl stop mssql-server
# Password for the SA user (required)
MSSQL_SA_PW="${{ parameters.saPassword }}"
# Product ID of the version of SQL server you're installing
# Must be evaluation, developer, express, web, standard, enterprise, or your 25 digit product key
MSSQL_PID="enterprise"
echo Running mssql-conf setup...
sudo MSSQL_SA_PASSWORD="$MSSQL_SA_PW" \
MSSQL_PID="$MSSQL_PID" \
/opt/mssql/bin/mssql-conf -n setup accept-eula
# Connect to server and get the version:
counter=1
errstatus=1
while [ $counter -le 5 ] && [ $errstatus = 1 ]
do
echo Waiting for SQL Server to start...
sleep 3s
/opt/mssql-tools/bin/sqlcmd \
-S localhost \
-U SA \
-P "$MSSQL_SA_PW" \
-Q "SELECT @@VERSION" 2>/dev/null
errstatus=$?
((counter++))
done
# Display error if connection failed:
if [ $errstatus = 1 ]
then
echo Cannot connect to SQL Server, installation aborted
exit $errstatus
fi
displayName: 'Configure SQL Server [Linux]'
Loading
Loading