FEAT: add standalone conda build pipeline + build-validation tooling

[Jahnvi Thakkar (jahnvi480)]

Work Item / Issue Reference

AB#47315

Summary

This pull request introduces a new standalone OneBranch pipeline for building, validating, and consolidating self-contained mssql-python conda packages across all supported platforms and Python versions. The pipeline is carefully structured to ensure per-platform correctness, best-effort artifact gathering, and robust isolation between build legs. It also includes a template job for consolidating conda artifacts and a .gitattributes update for shell scripts.

New Standalone Conda Build Pipeline
Major features and structure:

• Adds conda-build-pipeline.yml: Implements a full multi-stage pipeline that builds and validates self-contained mssql-python conda packages for Windows, macOS, and Linux, including cross-platform builds (e.g., win-arm64, osx-arm64, linux-aarch64) using platform-appropriate agents and emulation where needed. Each leg is carefully isolated to prevent failures in one subdir from impacting others, and best-effort logic is used for cross-arch builds.

• Artifact Consolidation:

  • Adds consolidate-conda-artifacts-job.yml: Provides a job template that collects all per-platform conda packages into a single artifact, preserving the subdir structure. The consolidation is best-effort in the build pipeline, with hard gating deferred to the release pipeline to avoid blocking primary wheel deliverables.

Build and Release Process Improvements

• Best-Effort and Gating Strategy: The pipeline is designed so that conda packaging failures do not block wheel releases. Completeness and artifact presence are strictly enforced only at release time, not during the build. [1] [2]

Cross-Platform and Cross-Arch Handling

• Cross-Build Logic: Implements cross-building for win-arm64, osx-arm64, and linux-aarch64 using CONDA_SUBDIR and QEMU emulation as appropriate, with architecture-specific validation and clear blast-radius isolation to prevent a single platform???????????????s failure from impacting others.

Repository Hygiene

• Shell Script Line Endings:
  • Adds OneBranchPipelines/scripts/.gitattributes enforcing LF line endings for .sh files under that folder (the conda recipe scripts are covered separately by conda/.gitattributes).

Build-Validation Tooling + Tests
The "build-validation tooling" named in the title -- the exact set of files in this slice:

• OneBranchPipelines/scripts/build_conda_packages.py: the single cross-platform orchestrator (gather wheels -> Miniforge/conda-build -> build the self-contained package -> masking-immune audit -> solve a fresh env + import + driver-load + optional reachability gate -> stage). Replaces the former per-OS PowerShell/bash build scripts.
• OneBranchPipelines/steps/conda-build-validate-step.yml + -posix.yml: the Windows / POSIX step templates that invoke the orchestrator.
• eng/scripts/audit_bundled_binaries.py, assert_pe_machine.py, assert_macho_arch.py, _conda_pkg.py: masking-immune RUNPATH, ELF/PE/Mach-O architecture, required Linux driver-inventory, and package-reader validation.
• requirements.txt: declares zstandard so .conda payload tests execute on Python versions without the stdlib compression.zstd backend.
• conda/driver_load_probe.py: the DB-less driver-load proof.
• tests/test_029_bundled_binary_audit.py, test_030_pe_machine_assert.py, test_033_driver_load_probe.py, test_034_conda_verify_cwd.py, test_035_conda_macho_assert.py: unit coverage for Linux payload completeness/RUNPATH, PE and Mach-O architecture checks, the driver-load probe, neutral-cwd verification, and blocking win-arm64 environment installation.

Not in this slice (deliberately): the live Encrypt=yes TLS gate (conda/tls_connect_probe.py and its test_028/test_031) is a release-pipeline concern -- the build pipeline never enables it (no leg sets CONDA_TLS_PROBE_CONN), so it ships with the release slice, not here. The masking-immune static RUNPATH audit already guards the OpenSSL layout at build time.

[Copilot]

🟡 Changes recommended

The Conda publish/release step templates contain a required-subdirs default mismatch and misleading guard error messages that can enable incorrect publishing behavior or slow diagnosis.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Adds standalone Conda build + release pipeline infrastructure for mssql-python, plus the validation/audit tooling (and unit tests) used to gate Conda artifacts independently of the wheel/PyPI release flow.

Changes:

• Introduces OneBranch standalone Conda build and Conda release/publish pipelines with shared step/job templates for per-platform build, consolidation, release gating, and publishing.
• Adds build-time and release-time validation tooling: Linux RUNPATH self-containment audit, Windows PE machine-type audit, release metadata gate, and release-time dependency re-solve gate.
• Adds a suite of pure unit tests (no DB / no native extension required) covering the new probes and validation scripts.

File summaries

File	Description
OneBranchPipelines/conda-build-pipeline.yml	Standalone Conda build pipeline consuming wheel artifacts and producing consolidated Conda artifacts.
OneBranchPipelines/conda-release-pipeline.yml	Standalone Conda release pipeline that gates completeness/consistency and optionally publishes to Anaconda.org.
OneBranchPipelines/jobs/consolidate-conda-artifacts-job.yml	Consolidates per-leg staged Conda packages into a single conda/ artifact tree.
OneBranchPipelines/steps/conda-build-validate-step.yml	Windows template to build/validate Conda packages from wheels and stage artifacts.
OneBranchPipelines/steps/conda-build-validate-step-posix.yml	POSIX template to build/validate Conda packages from wheels and stage artifacts.
OneBranchPipelines/steps/conda-release-step.yml	Release-readiness gate: re-audit + metadata validate consolidated Conda artifacts.
OneBranchPipelines/steps/conda-publish-step.yml	Publishes consolidated Conda packages to Anaconda.org using staged-then-promoted flow.
OneBranchPipelines/scripts/build-conda-packages.ps1	Windows implementation of Conda build+validate from wheel inputs (incl. audits and probes).
OneBranchPipelines/scripts/build-conda-packages.sh	POSIX implementation of Conda build+validate from wheel inputs (incl. audits and probes).
OneBranchPipelines/scripts/.gitattributes	Enforces LF for .sh scripts.
conda/driver_load_probe.py	DB-less driver load probe used as a Conda validation gate.
conda/tls_connect_probe.py	Live Encrypt=yes TLS probe to prove OpenSSL backend reachability (fail-closed classification).
conda/validate_conda_release.py	Metadata-based release readiness gate for Conda artifact completeness and consistency.
eng/scripts/assert_pe_machine.py	Audits PE machine type of vendored Windows binaries inside Conda packages.
eng/scripts/audit_bundled_binaries.py	Static, masking-immune audit of Linux vendored binaries’ RUNPATH/NEEDED/deps/vendoring rules.
eng/scripts/conda_resolve_check.py	Release-time dependency re-solve (dry-run) to catch channel drift before publish.
tests/test_026_driver_load_probe.py	Unit tests for conda/driver_load_probe.py classification and main() behavior via stubs.
tests/test_027_conda_release_metadata.py	Unit tests for conda/validate_conda_release.py matrix/subdir/version enforcement.
tests/test_028_tls_connect_probe.py	Unit tests for TLS probe classification, tokenization, redaction, and skip/guard behavior.
tests/test_029_bundled_binary_audit.py	Unit tests for Linux RUNPATH audit logic using synthetic ELF + conda package fixtures.
tests/test_030_pe_machine_assert.py	Unit tests for PE machine-type parser + .conda round-trip audit.
tests/test_031_tls_probe_required.py	Unit tests for TLS probe required-mode semantics (fail closed on misconfig).
tests/test_032_conda_resolve_check.py	Unit tests for conda re-solve helper (channel selection, cmd shape, target enumeration).

Review details

• Files reviewed: 23/23 changed files
• Comments generated: 3
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

📊 Code Coverage Report

🔥 Diff Coverage 100%

🎯 Overall Coverage 83%

📈 Total Lines Covered: 7959 out of 9522 📁 Project: mssql-python

---

Diff Coverage

Diff: main...HEAD, staged and unstaged changes

No lines with coverage information in this diff.

---

📋 Files Needing Attention

📉 Files with overall lowest coverage (click to expand)

mssql_python.pybind.logger_bridge.cpp: 57.9%
mssql_python.pybind.ddbc_bindings.h: 61.5%
mssql_python.pybind.logger_bridge.hpp: 70.8%
mssql_python.pybind.ddbc_bindings.cpp: 77.5%
mssql_python.row.py: 77.6%
mssql_python.pybind.connection.connection_pool.cpp: 81.6%
mssql_python.pybind.connection.connection.cpp: 84.4%
mssql_python.logging.py: 85.5%
mssql_python.helpers.py: 89.3%
mssql_python.pooling.py: 90.1%

---

🔗 Quick Links

⚙️ Build Summary	📋 Coverage Details
View Azure DevOps Build	Browse Full Coverage Report

[Copilot]

🔵 Needs a closer look

There are a few correctness/robustness issues in the new conda validation tooling (notably ODBC braced-string splitting edge cases and script rerunnability) plus misleading failure messages that should be fixed before relying on these gates.

Review details

Suppressed comments (5)

Previously missed (4) — in code that hasn't changed since the last review.

OneBranchPipelines/scripts/build-conda-packages.sh:142

• conda create -n conda_builder ... will fail on reruns because the env name is constant and the script never removes/reuses an existing env. This makes the script non-idempotent for local dev or agent/workdir reuse (and set -e will abort immediately).
  conda/tls_connect_probe.py:135
• _split_top_level treats every } as ending a braced value, but MS-ODBCSTR allows escaping a literal closing brace inside {...} as }}. With the current logic, a value containing }} can drop brace depth early and cause semicolons inside the braced value to be split at top level, corrupting the connection string rewrite.
  conda/driver_load_probe.py:135
• The probe is used for the self-contained conda package (ODBC payload vendored into mssql-python), so "missing companion" is misleading in the failure message and makes triage harder.
  conda/tls_connect_probe.py:110
• describe() prefixes any SSL Provider / certificate verification failure as "OpenSSL backend unreachable", but those errors can happen with OpenSSL present (they indicate a TLS handshake failure, not a missing libssl/libcrypto). This wording makes failures misleading to triage.

This issue also appears on line 279 of the same file.

conda/tls_connect_probe.py:282

• The failure exit text always says "TLS/OPENSSL BACKEND UNREACHABLE", but failures can also be due to TLS handshake errors (cert, protocol, etc.) where OpenSSL is reachable. Consider a neutral prefix so the exit reason matches what actually failed.

    if tls_completed(outcome):
        print("TLS_OK (OpenSSL backend reachable; " + describe(outcome) + ")")
        return
    sys.exit("TLS/OPENSSL BACKEND UNREACHABLE: " + describe(outcome))

• Files reviewed: 16/16 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Sumit Sarabhai (sumitmsft)]

Summary of review (automated pre-review, pending maintainer judgment)

Reviewed the added conda build pipeline and validation tooling for correctness, secret handling, validation-gate coverage, and repository conventions. The tooling is well-structured and high-coverage (ran the 5 new test files: 97 passed, 4 skipped for the optional zstd .conda path). All specifics are left as inline comments.

Requesting changes on two Medium items (inline): the brace-splitter divergence from the shipped connection-string parser in tls_connect_probe.py (connect-string corruption + password fragment in logs), and the non-secret condaTlsProbeConn pipeline parameter. The remaining inline comments are Low-severity suggestions and two questions.

Recommendation: Request Changes

[Gaurav Sharma (bewithgaurav)]

one thought on the two build scripts (build-conda-packages.ps1 + .sh).

they're the same pipeline written twice:

• same 7 steps, same 7 args
• one in powershell, one in bash
• ~440 lines of parallel logic, plus the same comments duplicated on both sides

the reason i'd push on it: they've already drifted.

• step 2 installs conda-build<26 into a dedicated env in the .sh, but into base in the .ps1
• the .sh comment literally explains that base is the thing that goes unsolvable on a 3.14-pinned runner
• so the ps1 is doing what the sh warns against. that's the gap
• two files means every change is a two-file change, and this one already diverged

also a big chunk of the ps1 complexity only exists because the yaml dot-sources it with &:

• the ErrorActionPreference flip, the 2>$null, the cmd /c "exit 0" reset at the end
• if the step just ran python build_conda_packages.py ... as a normal process, it reads the exit code and all of that goes away

suggestion: one build_conda_packages.py orchestrator.

• conda is python and every agent already has a bootstrap interpreter, so it runs everywhere
• the platform-specific bits (installer invocation, qemu vs ToS env, the linux-only reachability + tls gates) are a handful of if branches, not a second 360-line script
• both step templates collapse to one python ... call too

on effort: this is small.

• the scripts are short and well scoped, and the logic already exists
• it's collapsing two files into one, not writing new pipeline
• only real work is one ADO run to confirm the legs stay green

[Sumit Sarabhai (sumitmsft)]

Review Summary

• PR intent: Add a standalone conda build pipeline plus build-validation tooling (PE/ELF architecture asserts, bundled-binary audit, and TLS / driver-load reachability probes) for the mssql-python conda packages.
• Scope reviewed: The full PR diff at head SHA ae9e4a64 — the OneBranch conda pipeline YAML + step/job templates, the build scripts (build-conda-packages.ps1 / .sh), and the Python validation tooling under conda/ and eng/scripts/.
• Overall assessment: The build/validation design is careful and largely fail-closed. One Medium pipeline-wiring defect prevents the TLS gate from ever receiving its secret connection string, plus four Low-severity robustness gaps in the audit/probe tooling.
• Overall risk: Medium
• Proposed decision: Request Changes
• Design compliance: Not Applicable (no formal design/ADR governs this tooling)

Findings: 1 Medium, 4 Low — all posted inline.

Recommendation: Request Changes. The Medium (job-level secret never reaches the posix bash: step) should be fixed so the TLS gate actually runs against the intended connection; the four Low items are robustness hardening of the audit/probe tooling.

[Copilot]

🟡 Changes recommended

The conda orchestrator has reproducibility/correctness issues (channel pinning and version derivation) that can lead to non-deterministic builds or incorrectly stamped conda package versions.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 16/17 changed files
• Comments generated: 2
• Review effort level: Lite

[Sumit Sarabhai (sumitmsft)]

Two validation-gate correctness issues on this revision. Details inline; reasons summarized below.

1. Driver-load probe never reaches the native driver load (High). In conda/driver_load_probe.py the probe connection string contains a bare ****** token with no =. mssql_python.connect() runs Connection.__init__ -> _construct_connection_string -> _ConnectionStringParser(validate_keywords=True)._parse() before the native ddbc_bindings.Connection(...) load. _parse raises Incomplete specification: keyword '******' has no value (missing '=') for any token lacking = (that syntax check is not gated behind validate_keywords). The probe's own driver_loaded() classifier is fail-closed and only returns True on a clean connect or a recognized driver-loaded marker, so the parser ValueError is classified as not-loaded and the gate exits non-zero on every run regardless of payload health.

2. macOS presence gate does not require load-bearing helper dylibs (Medium). In eng/scripts/assert_macho_arch.py the presence counter is incremented only for libmsodbcsql*.dylib and the gate fails only when that counter is zero, so a package missing libodbcinst.2.dylib / libodbc.2.dylib / libltdl.7.dylib still passes. Because osx-arm64 skips the runtime import on the Intel agent, such a package passes static validation but can fail at dlopen on Apple Silicon.

[Copilot]

🟡 Changes recommended

The orchestrator currently passes a raw local channel path to conda -c, which can be unreliable/ambiguous on Windows without normalizing to a file:/// URL.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 16/17 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

The conda build orchestrator computes an effective target subdir but does not consistently use it when selecting channels/audits/verify behavior on native legs, which can break documented “empty condaTargetSubdir == native” execution paths.

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

OneBranchPipelines/scripts/build_conda_packages.py:857

• The orchestrator computes an effective target subdir (target = condaTargetSubdir or condaSubdir), but then passes args.conda_target_subdir (which can be empty on native legs) into build_packages(), audit_packages(), and verify(). This breaks native runs where condaTargetSubdir is intentionally empty (per the step template docs): channel selection/audits/verification will behave as if there is no target subdir, even though condaSubdir still defines what is being built/staged.

• Files reviewed: 16/17 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

The orchestrator currently doesn’t explicitly set conda-build’s croot despite templates/documentation implying outputDir is the croot, which can undermine isolation and path assumptions for the build legs.

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

OneBranchPipelines/scripts/build_conda_packages.py:351

• The step templates describe outputDir as the conda-build croot, but the orchestrator never sets conda-build’s croot (it only sets --output-folder). This means conda-build may still use its default croot (often under the user home), which can reintroduce the space/path and cross-leg isolation problems this pipeline is trying to avoid. Consider explicitly setting croot under outputDir when invoking conda-build (or update the template docs if that’s not intended).

• Files reviewed: 16/17 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

It introduces a large new cross-platform build pipeline and packaging/audit toolchain that impacts release-critical artifact production and should get final human validation in a real OneBranch run.

Review details

• Files reviewed: 16/17 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Sumit Sarabhai (sumitmsft)]

Prior findings are resolved. Targeted conda tests pass.

[Copilot]

🟡 Changes recommended

The orchestrator’s import-location gate is implemented via assert inside a generated python -c probe, which can be optimized away and undermines the fail-closed verification.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 16/17 changed files
• Comments generated: 1
• Review effort level: Lite