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, _conda_pkg.py: the masking-immune RUNPATH / ELF-arch / PE-machine static audit plus the shared conda-package reader.
• 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: unit coverage for the audit, the PE-machine assert, the driver-load probe, and the orchestrator's verify() neutral-cwd invariant.

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 82%

📈 Total Lines Covered: 7776 out of 9444 📁 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: 58.9%
mssql_python.pybind.ddbc_bindings.h: 61.5%
mssql_python.pybind.logger_bridge.hpp: 70.8%
mssql_python.pybind.ddbc_bindings.cpp: 75.6%
mssql_python.__init__.py: 77.6%
mssql_python.row.py: 77.6%
mssql_python.pybind.connection.connection_pool.cpp: 82.8%
mssql_python.pybind.connection.connection.cpp: 84.4%
mssql_python.logging.py: 85.5%
mssql_python.connection.py: 85.9%

---

🔗 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

There are documentation/scope mismatches (including discrepancies between the PR description and the files actually present) that should be corrected before merging.

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

Review details

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

[Copilot]

🔵 Needs a closer look

There are a few concrete correctness/robustness issues in the new tests/templates and consolidation script (sys.path leakage, quoting/strict bash mode, and .gitattributes scope vs PR description) that should be addressed before approval.

Review details

Suppressed comments (6)

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

OneBranchPipelines/jobs/consolidate-conda-artifacts-job.yml:82

• This script uses unquoted variable expansions (e.g., $(ob_outputDirectory), $(Pipeline.Workspace)) and only set -e. Quoting and set -euo pipefail makes the consolidation more robust (paths with spaces, unset vars) and prevents subtle failures from being masked.

This issue also appears on line 87 of the same file.
tests/test_029_bundled_binary_audit.py:40

• _load_module() prepends eng/scripts to sys.path but never removes it, which can leak into other tests and change import resolution order for the rest of the session. Wrap the prepend in a try/finally and pop it back off after exec_module().
  tests/test_030_pe_machine_assert.py:36
• _load_module() prepends eng/scripts to sys.path but never restores it, which can affect imports in later tests. Use a try/finally around the sys.path change so it’s removed after exec_module().
  OneBranchPipelines/scripts/.gitattributes:1
• PR description says this enforces LF for all .sh scripts, but this .gitattributes only applies under OneBranchPipelines/scripts/ (and there’s a separate conda/.gitattributes). If the intent is repo-wide enforcement, consider moving the rule to a root .gitattributes (and avoiding per-directory duplication).
  OneBranchPipelines/steps/conda-build-validate-step-posix.yml:47
• The parameter comment says the step appends the target subdir to outputDir, but the orchestrator actually appends condaSubdir (the leg’s display/staging subdir). This mismatch makes it harder to reason about how directory isolation works on shared agents.

OneBranchPipelines/jobs/consolidate-conda-artifacts-job.yml:92

• The find/cp pipeline uses unquoted $(Pipeline.Workspace) / $(ob_outputDirectory) expansions. These are paths and should be quoted to avoid word-splitting or globbing if the agent directory contains spaces or special characters.

          while IFS= read -r p; do
            subdir=$(basename "$(dirname "$p")")
            mkdir -p "$(ob_outputDirectory)/conda/$subdir"
            cp -v "$p" "$(ob_outputDirectory)/conda/$subdir/"
            found=1
          done < <(find $(Pipeline.Workspace)/all-artifacts -type f \( -name 'mssql-python*.conda' -o -name 'mssql-python*.tar.bz2' \))

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

[Sumit Sarabhai (sumitmsft)]

Scheduled Copilot review — conda build pipeline + build-validation tooling

Recommendation: Approve with Minor Changes (2 Low, non-blocking). Overall risk: Low. Design compliance: Not Applicable (no formal ADR governs this CI/packaging tooling).

Reviewed the true PR scope (three-dot origin/main...55e56c43, 14 conda/build-tooling files) for correctness, security/trust boundaries, supply chain, cross-platform/arch coverage, fail-closed behavior, tests, and repository conventions. All prior-round findings are resolved. The orchestrator is injection-safe (list-form subprocess), SHA256-verifies Miniforge before execution, keeps fail-closed static audits, and pins the conda version to the ESRP-signed wheel filename. Two small non-blocking gaps are noted inline.

Questions / Needs Verification (non-blocking)

• win-arm64 real conda create failure is treated as infrastructure (build_conda_packages.py ~467-477): any nonzero exit from the real create is logged and skipped after the blocking --dry-run solve. Arch is still enforced by the PE-machine assert and solvability by the dry-run, and nothing ships (build-only) — please confirm a genuinely-broken-but-solvable package can't stage undetected on this leg.
• gather_wheels uses odbc_matches[0] (build_conda_packages.py ~97) while copying all mssql matches. Per-leg odbcWheelFilter values are arch-specific and pip's platform-tag enforcement would reject a wrong-arch pick, so [0] is safe in practice — please confirm the odbc drop can only ever contain one wheel matching each filter, else consider asserting len(odbc_matches) == 1.
• Linux audit does not assert a required distro SET (audit_bundled_binaries.py 438-443, documented): a wholesale-missing distro payload passes the audit, and on the emulated linux-aarch64 leg the driver-probe failure is swallowed — please confirm the wheel-build validation is the intended source of truth for distro-set completeness.

[Sumit Sarabhai (sumitmsft)]

audit_packages runs the PE-machine assert only for win-arm64. osx-arm64 is cross-built on the Intel agent so its runtime import auto-skips (verify lines 504-511), and — as the pipeline comment at conda-build-pipeline.yml:216-218 notes — its arch is trusted purely from the universal2 filename tag with no Mach-O check. A payload missing its arm64 slice would build, solve, skip execution, and stage. This is Low (documented, continueOnError, build-only, slices validated upstream at wheel build), but consider closing the asymmetry with win-arm64 by adding a static Mach-O slice assert (parse the fat header / lipo -archs) for the osx legs.

[Sumit Sarabhai (sumitmsft)]

iter_payload_members has no final else, so a path that is neither .conda nor .tar.bz2 yields an empty iterator silently (fail-open), whereas read_index (line 88) raises ValueError("unrecognized conda package extension") for the same case. It's currently unreachable (the audit globs only *.conda/*.tar.bz2), so this is latent — but for fail-closed consistency and future callers, consider adding else: raise ValueError(f"{path}: unrecognized conda package extension").