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: 7963 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: 82.8%
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]

🔵 Needs a closer look

It introduces a large, cross-platform build pipeline and new packaging/audit orchestration where correctness depends on environment-specific behavior that requires final human validation.

Review details

Suppressed comments (1)

OneBranchPipelines/scripts/build_conda_packages.py:407

• _is_emulated_cross() currently treats any -arm64/-aarch64 cross on a non-arm host as "emulated" and logs that runtime probes are best-effort under QEMU. That message (and the boolean) is incorrect for win-arm64 and osx-arm64, which are cross-built without QEMU; it can mislead debugging and conflates two different concepts ("target python not executable" vs "qemu emulation"). Restrict this helper to the actual QEMU case (linux-aarch64 on non-arm) so logs/behavior stay accurate.

    if target_subdir.endswith(("aarch64", "arm64")) and host not in ("aarch64", "arm64"):
        _log(
            f"NOTE: emulated CROSS leg (CONDA_SUBDIR={target_subdir} on {host}); runtime driver "
            f"probes are best-effort under QEMU binfmt, build/audit/import remain blocking."
        )

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

[Copilot]

🔵 Needs a closer look

It introduces substantial new pipeline infrastructure plus new cross-platform packaging/audit logic that warrants final human validation in the target CI/CD environment before approval.

Review details

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

[Copilot]

🔵 Needs a closer look

It introduces substantial new cross-platform pipeline/build-validation logic where correctness depends on Azure DevOps runtime behavior and multi-OS edge cases that warrant final human verification.

Review details

Suppressed comments (2)

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

OneBranchPipelines/conda-build-pipeline.yml:346

• The consolidation stage is described as best-effort, but without an explicit stage condition it won’t run if any of the upstream Conda stages fail (default stage condition is succeeded()). That prevents collecting partial outputs for diagnosis and contradicts the template’s “never hard-fails” consolidation intent.

Set the stage condition to succeededOrFailed() (or always()) so consolidation still runs and publishes whatever conda artifacts exist.
OneBranchPipelines/jobs/consolidate-conda-artifacts-job.yml:48

• This job is intended to be best-effort (“never hard-fails on a short set”), but condition: succeeded() will skip it when any dependency fails, so you lose consolidation output/logs exactly when they’re most needed.

Use succeededOrFailed() (or always()) so the job still consolidates and publishes whatever artifacts are available.

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

[Copilot]

🔵 Needs a closer look

It introduces a large amount of new CI/pipeline and packaging/audit logic across multiple platforms/architectures that warrants final human review of end-to-end behavior in the target build environment.

Review details

Suppressed comments (1)

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

OneBranchPipelines/scripts/build_conda_packages.py:71

• run_capture is typed as returning a bare tuple, which loses the (rc, output) contract and makes type checking less effective (mypy is part of the repo tooling). Consider annotating the return as tuple[int, str] to match how callers unpack it.

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

[Gaurav Sharma (bewithgaurav)]

went through the conda build pipeline and validation tooling. the overall approach looks good and the earlier review feedback is addressed. one test issue remains inline, so requesting changes on that.

[Gaurav Sharma (bewithgaurav)]

on a 2nd review, found 2 more suggestions. both are inline.

the earlier feedback is addressed: the build scripts are consolidated, the linux reachability check remains intact, and osx-arm64 now has a static Mach-O check.

the zstd fallback test remains the merge-blocking issue. these two are smaller fail-closed and partial-diagnostics gaps.

[Copilot]

🟡 Changes recommended

OneBranchPipelines/conda-build-pipeline.yml has an invalid YAML indentation for demands, which can break the pipeline configuration.

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

Review details

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

[Copilot]

🟢 Approval recommended

The pipeline/orchestrator flow and the associated audit+test coverage appear consistent and fail-closed where intended, with no confirmed correctness or safety issues found in the reviewed diffs.

Review details

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

[Gaurav Sharma (bewithgaurav)]

re-reviewed the latest changes. the zstd fallback test, fail-closed subdir validation, and partial artifact publishing gaps are fixed.

the additional helper error handling is also in place, and all checks are green. approving.

[Gaurav Sharma (bewithgaurav)]

non-blocking I guess - one last thing I noticed before this merges.

this pipeline can pick wheels from any successful branch build, not just main. scheduled runs are marked Official, so if the newest successful wheel build came from a feature branch, those wheels could be packaged by mistake.

we already have successful non-main runs in pipeline 2199, so this can happen.

can we make main the default, and block Official runs when the selected wheel build is not from main? manual NonOfficial runs can still use branch builds for testing.

official-release-pipeline.yml has the same gap, so we should fix that separately too.