FEAT: Add Conda release and publish tooling for mssql-python

[Jahnvi Thakkar (jahnvi480)]

Work Item / Issue Reference

AB#47315

Summary

This pull request introduces a new GitHub Actions workflow for auditing conda package builds and adds a standalone OneBranch pipeline for validating and publishing conda releases. These changes ensure that conda packages are properly built, audited for security, and published only after passing rigorous validation, with a dry-run mode for safe verification before production releases.

New conda package auditing and release validation:

• GitHub Actions workflow for conda audit:
  Adds .github/workflows/conda-audit.yml to automatically build and audit linux-64 conda packages on pull requests. This workflow fetches PyPI wheels, builds the package, and runs multiple audit tests to catch regressions in dependencies, binary layout, or provenance before merging.

Standalone OneBranch pipeline for conda releases:

• Conda release pipeline definition:
  Introduces OneBranchPipelines/conda-release-pipeline.yml, a decoupled pipeline that validates the conda package set for completeness, provenance, and correctness before publishing to Anaconda.org. The pipeline supports a dry-run mode (default) that prints the exact upload plan without publishing, and a production mode for real releases.
• Dry-run and production publish modes:
  The pipeline defaults to a dry-run (validate-only) mode for safety, only uploading to Anaconda.org when explicitly enabled. This helps prevent accidental releases and allows teams to review the release plan in advance.
• Automated provenance and artifact validation:
  The pipeline verifies the source and build provenance of the conda artifacts, ensuring they match the expected versions and were produced by the correct upstream pipeline, further increasing release integrity.

These additions strengthen the security, traceability, and reliability of the conda package release process.

[Copilot]

Pull request overview

This PR adds initial conda packaging assets for mssql-python (and its mssql-python-odbc companion) so the project can be published to the Microsoft-owned microsoft Anaconda channel, alongside the existing PyPI wheel distribution.

Changes:

• Adds conda recipes for mssql-python and mssql-python-odbc that repackage existing wheels (no compilation).
• Adds a local PowerShell harness to build both recipes, create a local channel, and validate import / optional live-connect.
• Adds a draft OneBranch stage to build/test/publish conda artifacts from signed release artifacts.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 6 comments.

File	Description
conda/onebranch-publish-conda-stage.yml	Draft OneBranch stage to build from signed artifacts, gate on smoke tests, and publish to the microsoft Anaconda channel.
conda/mssql-python/meta.yaml	Conda recipe for repackaging the mssql-python wheel and depending on a version-locked mssql-python-odbc.
conda/mssql-python-odbc/meta.yaml	Conda recipe for repackaging the proprietary driver wheel into a companion conda package.
conda/build_and_test_local.ps1	Local “test-before-live” harness to build, index, install, and smoke test the conda packages.

Suppressed comments (1)

conda/onebranch-publish-conda-stage.yml:133

• Same string-vs-boolean condition issue here: quoting the template expression turns it into a string, which can cause the publish step to be skipped unexpectedly even when publishToConda is true.

          - task: PowerShell@2
            displayName: 'Publish to anaconda.org/microsoft'
            condition: and(succeeded(), eq('${{ parameters.publishToConda }}', true))

---

💡 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: 8437 out of 10091 📁 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.performance_counter.hpp: 0.7%
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.row.py: 77.6%
mssql_python.pybind.ddbc_bindings.cpp: 77.7%
mssql_python.pybind.connection.connection_pool.cpp: 81.8%
mssql_python.logging.py: 86.2%
mssql_python.pooling.py: 90.1%
mssql_python.pybind.py_type_cache.hpp: 91.6%

---

🔗 Quick Links

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

[Copilot]

Pull request overview

Copilot reviewed 24 out of 24 changed files in this pull request and generated 3 comments.

Suppressed comments (4)

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

• The verify env name only includes the Python version. On macOS this script is invoked twice on the same agent (native osx-arm64, then cross-target osx-64), so the second conda create -n verify_... can fail with an existing prefix or reuse the wrong-arch env. Include the effective subdir (native vs $CONDA_SUBDIR) in the env name to avoid collisions.

for py in $pyvers; do
  envName="verify_${py//./}"
  echo "=== [py $py] create verify env from local channel ==="

OneBranchPipelines/stages/build-linux-single-stage.yml:116

• This apt install runs before the later apt-get update in the job, so it can fail on agents with stale apt indices (common on hosted Ubuntu). Add an apt-get update (and ideally noninteractive) before installing qemu-user-static/libc6-arm64-cross.

              # qemu-user-static: run aarch64 ELF binaries on the x86_64 host.
              # libc6-arm64-cross: the aarch64 glibc runtime (loader + libc/libm/...)
              # under /usr/aarch64-linux-gnu so qemu can resolve /lib/ld-linux-aarch64.so.1
              # for the emulated aarch64 conda build/verify (QEMU_LD_PREFIX points here).
              sudo apt-get install -y qemu-user-static libc6-arm64-cross

OneBranchPipelines/steps/conda-publish-step.yml:91

• Installing anaconda-client from PyPI without pinning a version can make releases non-reproducible and may unexpectedly break publishing if a new release introduces behavioral changes. Consider pinning to a vetted version (or using a constraints file) so publish behavior is stable.

        $ErrorActionPreference = 'Stop'
        python -m pip install --upgrade pip
        python -m pip install anaconda-client
        # anaconda-client installs the `anaconda` console script onto PATH.
        anaconda --version

OneBranchPipelines/steps/conda-build-validate-step.yml:126

• The error message references $links (the wheel find-links directory), but conda packages are searched under ${{ parameters.outputDir }}/bld. If this trips, the message will mislead troubleshooting.

      if (-not $built) { Write-Error "No conda packages were produced under $($links)"; exit 1 }

[Copilot]

Pull request overview

Copilot reviewed 28 out of 28 changed files in this pull request and generated no new comments.

Suppressed comments (2)

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

• The verify env name is only based on the Python version (e.g. "verify_310"). On macOS this script is invoked twice on the same agent (osx-64 and osx-arm64) sharing the same Miniforge install/outputDir, so the second invocation will fail when it tries to create an env that already exists. Include the target subdir in the env name (and/or delete any existing env before creating it) so the two runs don’t collide.

for py in $pyvers; do
  envName="verify_${py//./}"
  echo "=== [py $py] create verify env from local channel ==="
  # -c microsoft (ahead of conda-forge) so azure-core/azure-identity/msal resolve from the
  # lean `microsoft` channel, NOT conda-forge whose azure-core recipe over-declares flask/six
  # -> celery/boto3/botocore (~9 MB); see conda-forge/azure-core-feedstock#71.
  # --strict-channel-priority keeps the freshly built local companion + binding authoritative.
  "$conda" create -y -n "$envName" -c "$bld" -c microsoft -c conda-forge --strict-channel-priority --override-channels "python=$py" mssql-python

conda/validate_conda_release.py:67

• read_index_json() uses next(...) to locate the info-*.tar.zst member inside a .conda. If the archive is malformed (missing that member), this will raise StopIteration and produce a stack trace rather than a clear validation failure message. Handle the empty case and raise a ValueError with a helpful message instead.

        with zipfile.ZipFile(path) as zf:
            info_name = next(
                n for n in zf.namelist() if n.startswith("info-") and n.endswith(".tar.zst")
            )
            info_blob = zf.read(info_name)

[Copilot]

🟡 Changes recommended

One or more issues must be addressed before approval.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (1)

conda/README.md:80

• This status text says publication/provenance tooling is proposed in a separate PR, but this change adds eng.conda_tools.provenance, publication, the standalone release pipeline, and an explicit publishToConda=true production path. The same page documents invoking provenance and promote, so the caveat is self-contradictory and can cause operators to treat the shipped release path as unavailable; update it to describe the explicit, manually gated path instead.

Run this existing build workflow only in a disposable isolated installation: shared-environment
ownership hardening is outside this change. Publication/provenance tooling is proposed
in a separate release-additions PR that follows this native/tooling foundation; see the
[release status and qualification caveats](../README.md#installation).

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

[Copilot]

🔵 Needs a closer look

Five moderate findings remain, including unavailable audit inputs and uncontrolled archive or provenance error paths.

Review details

Suppressed comments (5)

.github/workflows/conda-audit.yml:89

• This PR's current checkout is version 1.15.0 and fetch-wheels derives the requested versions from setup.py, so this step will query PyPI for the 1.15.0 binding/ODBC pair (and the current RS provider when required). The PR description explicitly says that verified public 1.15.0 wheel metadata/hashes are not available yet and that the 1.14.0 pair is only an older control; consequently the PR-triggered audit will fail before building the package until those public inputs exist. Gate this job on an available qualification profile or add an explicit readiness condition instead of unconditionally fetching the unpublished current release.

          python -m eng.conda_tools fetch-wheels \
            --wheel-dir "$PWD/wheels" --requirements-file "$PWD/wheel-inputs.txt" \
            --python-tag cp311 --conda-subdir linux-64

eng/conda_tools/archive.py:209

• read_release_index() uses decompress_index() for .conda metadata, but this helper returns backend ZstdError exceptions unchanged, unlike zstd_decompress(). A corrupt compressed info component can therefore bypass the release gate's ValueError handling and produce an uncontrolled failure; normalize decoder errors to ValueError here.

def decompress_index(raw: bytes) -> bytes:
    decode, _ = _zstd_decoder("metadata")
    return decode(raw)

eng/conda_tools/provenance.py:179

• json.load(response) is returned without checking its type. A syntactically valid but malformed ADO response such as a JSON array then reaches _verify_run, where .get(...) raises AttributeError; provenance.cli() intentionally does not catch that class, so the pipeline emits a traceback instead of the single-line controlled error promised by this boundary. Validate that the decoded payload is a dict and raise ValueError before returning it.

    with build_opener(_NoRedirect()).open(request, timeout=60) as response:
        return json.load(response)

eng/conda_tools/release.py:430

• collect_packages() reaches the archive readers, which can raise zipfile.BadZipFile, tarfile.TarError, EOFError, and KeyError from archive.READ_ERRORS, but this boundary catches only ValueError. A corrupt or truncated release artifact therefore escapes python -m eng.conda_tools validate with a traceback instead of the controlled non-zero gate result; catch the full archive error tuple here.

    except ValueError as exc:

eng/conda_tools/release.py:475

• The installed-input pass reads each package payload again, so malformed tar/zip payloads can raise the same archive.READ_ERRORS exceptions here. Because this second boundary also catches only ValueError, validate --release-versions can still terminate with an uncaught traceback after the metadata phase succeeds; use the archive error tuple for this handler as well.

        except ValueError as exc:

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

[Copilot]

🟡 Changes recommended

Critical wheel-target and payload-ownership validation issues, plus a provenance ID issue, remain unresolved.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (4)

.github/workflows/conda-audit.yml:45

• The path filter omits setup_odbc.py and mssql_python_odbc/**, even though the Conda build consumes the ODBC wheel produced by setup_odbc.py (OneBranchPipelines/stages/build-odbc-all-stage.yml:104-115) and vendors that package tree. A PR changing the ODBC packager or payload can therefore skip this audit. Include the ODBC build script and package tree in the trigger paths.

      - 'setup.py'
      - 'mssql_python/__init__.py'
      - 'mssql_python_odbc/__init__.py'

.github/workflows/conda-audit.yml:91

• fetch-wheels derives its versions from the current checkout, so this job requests the current 1.15.0 binding/ODBC pair from PyPI on every matching PR. The PR description says only the older public 1.14.0 pair is currently hash-qualified and that verified 1.15.0 wheel metadata/hashes are still pending; until those artifacts are available, this workflow fails at the fetch step for every relevant PR. Gate the job on a verified public profile or explicitly skip it with a visible status until the 1.15.0 inputs are available.

          python -m eng.conda_tools fetch-wheels \
            --wheel-dir "$PWD/wheels" --requirements-file "$PWD/wheel-inputs.txt" \
            --python-tag cp311 --conda-subdir linux-64

conda/README.md:102

• This new section says publication/provenance tooling is included, but the same document still states at lines 84-85 that it is proposed in a separate release-additions PR. That contradiction can send maintainers to obsolete release instructions; update the stale status text as part of this change.

Release matrix and Python-admissibility policy live in `release.py`, recorded
Azure DevOps source checks in `provenance.py`, source-bound component inputs and
public wheel fetching in `inputs.py`, and staged publication/recovery in `publication.py`. Both release
and native auditing use `archive.py`; release validation retains its stricter
container and index rules rather than weakening them to the generic audit policy.

eng/conda_tools/provenance.py:127

• resources.pipelines.<alias>.pipeline.id is the referenced pipeline definition ID; the selected execution ID is in runId (the YAML already distinguishes pipelineID from runID at OneBranchPipelines/conda-release-pipeline.yml:142-143). Treating pipeline.id as wheel_run_id makes this guard query the definition ID as if it were a run, so the real provenance check will fail or inspect the wrong wheel run. Read and validate runId, and separately require pipeline.id == _WHEEL_PIPELINE_ID; the fixture needs to model that response shape too.

    # ADO records the selected run ID in the nested pipeline.id and its build number
    # in version. The authoritative Build response supplies the actual definition ID.
    wheel_resource = run.get("resources", {}).get("pipelines", {}).get("buildPipeline", {})
    wheel_run_id = _positive_id(wheel_resource.get("pipeline", {}).get("id"))

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

[Copilot]

🟡 Changes recommended

Unresolved publication, provenance, and release-validation findings block safe approval.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (4)

OneBranchPipelines/steps/conda-publish-step.yml:203

• BINSTAR_CONFIG_DIR is configured as the client’s isolated configuration directory, but the file is written below an extra data subdirectory. The following get_config() check therefore does not prove that the pinned client loaded this file and can fall back to ambient agent configuration, defeating the endpoint/SSL isolation claimed by this gate. Write config.yaml directly under BINSTAR_CONFIG_DIR (or pass the explicit file path to the pinned client).

        $clientConfigDir = Join-Path $env:BINSTAR_CONFIG_DIR 'data'
        New-Item -ItemType Directory -Force -Path $clientConfigDir | Out-Null
        @('url: https://api.anaconda.org', 'ssl_verify: true') |
          Set-Content -Path (Join-Path $clientConfigDir 'config.yaml') -Encoding ASCII
        python -c "from binstar_client.utils import get_config; c=get_config(); assert c['url']=='https://api.anaconda.org'; assert c['ssl_verify'] is True; print('Anaconda endpoint configuration verified')"

eng/conda_tools/provenance.py:129

• resources.pipelines.buildPipeline.pipeline.id is the referenced wheel pipeline definition ID, not the selected wheel run ID (the wheel definition is 2199 in OneBranchPipelines/conda-build-pipeline.yml:69-74 and the resource carries the selected build number in version). Treating it as wheel_run_id makes the normal path query build/run 2199 instead of the recorded upstream run, so provenance will reject or validate the wrong build. Resolve the run by the referenced definition plus build number, or persist/pass the upstream run ID explicitly before calling the Runs API.

    # ADO records the selected run ID in the nested pipeline.id and its build number
    # in version. The authoritative Build response supplies the actual definition ID.
    wheel_resource = run.get("resources", {}).get("pipelines", {}).get("buildPipeline", {})
    wheel_run_id = _positive_id(wheel_resource.get("pipeline", {}).get("id"))
    wheel_build = get_json(f"build/builds/{wheel_run_id}?api-version=7.1")
    if not wheel_resource.get("version") or wheel_resource["version"] != wheel_build.get(

eng/conda_tools/release.py:149

• The ABI scan only recognizes *_cpXY; a non-normal ABI pin such as python_abi 3.13.* *_cp313t is ignored while the py313 build token still identifies the package as 3.13. The release matrix can therefore accept a free-threaded package in the normal CPython cell. Reject unsupported python_abi build pins (or explicitly parse and reject the t form) and add a regression case.

        match = _PY_ABI_RE.fullmatch(str(dep).strip())
        if match:
            abi_minors.add(f"{match.group(1)}.{match.group(2)}")
            abi_minors.add(f"{match.group(3)}.{match.group(4)}")

eng/conda_tools/release.py:160

• The patch sampler starts with only patch 0, so a two-component lower-bound/exclusion such as python >3.12 or python !=3.12 is evaluated only at 3.12.0 and is incorrectly reported as excluding the entire minor. The existing requirement cases expect these constraints to admit a later stable 3.12 patch; include a post-zero candidate (or otherwise sample the interval after a two-component boundary).

        patches = {0}
        # For the supported comparisons, truth can change only at a named patch

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

[Gaurav Sharma (bewithgaurav)]

the earlier Python compatibility issue is addressed. the added packaging protection is non-blocking hardening. approving.

[Copilot]

🟡 Changes recommended

Critical archive, audit, and wheel-validation gaps plus provenance and publishing issues remain unresolved.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (3)

OneBranchPipelines/steps/conda-publish-step.yml:204

• BINSTAR_CONFIG_DIR is the directory anaconda-client uses for config.yaml, but this writes the file under a nested data directory. Therefore the following get_config() check does not verify the file just written, and the upload CLI can fall back to ambient/default configuration instead of the intended endpoint/SSL policy. Write config.yaml directly under $env:BINSTAR_CONFIG_DIR (or set the environment variable to the parent of data).

        $clientConfigDir = Join-Path $env:BINSTAR_CONFIG_DIR 'data'
        New-Item -ItemType Directory -Force -Path $clientConfigDir | Out-Null
        @('url: https://api.anaconda.org', 'ssl_verify: true') |
          Set-Content -Path (Join-Path $clientConfigDir 'config.yaml') -Encoding ASCII

eng/conda_tools/provenance.py:128

• resources.pipelines.<alias>.pipeline.id is the upstream pipeline definition ID; the selected run is carried in runId. Reading pipeline.id as wheel_run_id makes the real release query build/builds/2199 (the wheel definition) instead of the selected run (for example, 173176), so _verify_run rejects the artifact before publication. Read and validate runId separately from the definition ID, and update the fixture to model that response shape.

    wheel_resource = run.get("resources", {}).get("pipelines", {}).get("buildPipeline", {})
    wheel_run_id = _positive_id(wheel_resource.get("pipeline", {}).get("id"))
    wheel_build = get_json(f"build/builds/{wheel_run_id}?api-version=7.1")

tests/test_036_conda_provenance.py:538

• This fixture encodes the same incorrect contract as the implementation: it places the wheel run ID in pipeline.id. In the ADO pipeline-resource response, pipeline.id should be the wheel definition (2199) and the selected run should be in runId; otherwise the test cannot catch the production lookup failure.

        "buildPipeline": {"pipeline": {"id": 173176}, "version": "26250.2"}

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

[Copilot]

🟡 Changes recommended

Three critical and one moderate review findings remain unresolved.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (1)

OneBranchPipelines/steps/conda-publish-step.yml:204

• anaconda-client treats BINSTAR_CONFIG_DIR as the directory containing config.yaml, but this writes the file under an extra data subdirectory. The client therefore does not use the endpoint/SSL settings prepared here and may fall back to an ambient/default configuration, defeating the isolation this publishing boundary relies on. Write config.yaml directly under $env:BINSTAR_CONFIG_DIR (and verify that path).

        $clientConfigDir = Join-Path $env:BINSTAR_CONFIG_DIR 'data'
        New-Item -ItemType Directory -Force -Path $clientConfigDir | Out-Null
        @('url: https://api.anaconda.org', 'ssl_verify: true') |
          Set-Content -Path (Join-Path $clientConfigDir 'config.yaml') -Encoding ASCII

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

[Sumit Sarabhai (sumitmsft)]

The current release path has unresolved provenance, publication-concurrency, bounded-archive-processing, and audit-reproducibility gaps. These should be addressed before enabling production Conda publication.

Recommendation: Request changes.

[Copilot]

🟡 Changes recommended

Unresolved moderate and critical findings block approval.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (3)

.github/workflows/conda-audit.yml:66

• This PR gate installs an unpinned pytest and a version-only zstandard from public PyPI, so the code that decides whether the audit passes is not reproducible or hash-verified. The existing build/test workflows use --require-hashes with generated locks (for example eng/requirements-test-linux.txt), so this workflow should use a reviewed hash-locked test dependency set instead of resolving mutable artifacts.

          python -m pip install --quiet --only-binary=:all: pytest "zstandard==0.23.0"

OneBranchPipelines/steps/conda-publish-step.yml:205

• BINSTAR_CONFIG_DIR is the directory in which binstar_client.utils.get_config() looks for config.yaml, but this writes the file under $BINSTAR_CONFIG_DIR/data/config.yaml. The verification at the next line therefore does not validate the isolated file (and publication may fall back to defaults), so the endpoint/configuration isolation promised by this task is not actually established. Write directly to Join-Path $env:BINSTAR_CONFIG_DIR 'config.yaml'.

        $clientConfigDir = Join-Path $env:BINSTAR_CONFIG_DIR 'data'
        New-Item -ItemType Directory -Force -Path $clientConfigDir | Out-Null
        @('url: https://api.anaconda.org', 'ssl_verify: true') |
          Set-Content -Path (Join-Path $clientConfigDir 'config.yaml') -Encoding ASCII
        python -c "from binstar_client.utils import get_config; c=get_config(); assert c['url']=='https://api.anaconda.org'; assert c['ssl_verify'] is True; print('Anaconda endpoint configuration verified')"

eng/conda_tools/provenance.py:76

• This API boundary assumes build.get("definition", {}) is always a mapping. A valid JSON response with definition: null or a scalar raises AttributeError, which provenance.cli() does not classify as an expected API/input failure, so the pipeline emits a traceback instead of a controlled refusal. Validate nested response shapes before dereferencing them.

def _verify_run(build: dict, run: dict, pipeline_id: int, run_id: int) -> dict:
    if build.get("id") != run_id or build.get("definition", {}).get("id") != pipeline_id:
        raise ValueError(f"Build API identity mismatch for pipeline {pipeline_id}, run {run_id}.")

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

[Copilot]

🟡 Changes recommended

Unresolved critical and moderate findings remain in the release pipeline, path validation, provenance handling, release-version logic, and audit workflow.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (3)

.github/workflows/conda-audit.yml:93

• This job derives the requested wheel versions from the checkout and then requires those exact versions to already exist on PyPI. The repository's release procedure bumps setup.py and mssql_python/__init__.py in the release PR before publication, so a normal release PR will hit a PyPI 404 here and fail the required check. Exclude release PRs from this PyPI-repackaging job or audit the last published version instead.

          python -m eng.conda_tools fetch-wheels \
            --wheel-dir "$PWD/wheels" --requirements-file "$PWD/wheel-inputs.txt" \
            --python-tag cp311 --conda-subdir linux-64

eng/conda_tools/provenance.py:130

• This reads the Azure DevOps pipeline-resource definition ID as the upstream wheel run ID. In the Runs API, resources.pipelines.<alias>.pipeline.id identifies the pipeline definition, while the selected run is under the resource's run.id; with the current code this can query build 2199 (the wheel pipeline definition) as though it were a run and make provenance validation fail or inspect the wrong record. Validate the definition ID against _WHEEL_PIPELINE_ID and extract the run ID from run.id before calling the Build API.

    wheel_resource = run.get("resources", {}).get("pipelines", {}).get("buildPipeline", {})
    wheel_run_id = _positive_id(wheel_resource.get("pipeline", {}).get("id"))
    wheel_build = get_json(f"build/builds/{wheel_run_id}?api-version=7.1")
    if not wheel_resource.get("version") or wheel_resource["version"] != wheel_build.get(
        "buildNumber"

eng/conda_tools/release.py:421

• --release-versions may be supplied without a value and mssqlPythonVersion is documented as optional, but this unconditional comparison makes that source-bound mode fail whenever no override is passed. The later expected_versions construction also omits the verified binding version in that case, so simply removing the comparison would allow the Conda index version to drift from the verified source version. Derive the expected binding version from versions whenever source-bound validation is enabled, or explicitly require the override and align the template/help with that contract.

        if args.release_versions is not None:
            versions = inputs.parse_release_versions(args.release_versions)
            if args.mssql_python_version != versions["mssql-python"]:
                raise ValueError(
                    "Binding release version differs from verified component versions."

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

[Copilot]

🔵 Needs a closer look

The PR audit mishandles unreleased release-PR versions, and provenance uses the pipeline definition ID instead of the selected run ID.

Review details

Suppressed comments (2)

.github/workflows/conda-audit.yml:93

• This PR-triggered job derives the exact versions from the checked-out setup.py and __init__.py, then immediately requires those versions to exist on PyPI. The documented release flow updates those files in a release PR before publication, so the release PR will receive a 404 here and cannot pass the audit; add an unpublished-version/release-PR path or defer this fetch until the wheels are published.

          python -m eng.conda_tools fetch-wheels \
            --wheel-dir "$PWD/wheels" --requirements-file "$PWD/wheel-inputs.txt" \
            --python-tag cp311 --conda-subdir linux-64

eng/conda_tools/provenance.py:127

• The Azure DevOps pipeline-resource payload exposes the selected upstream run as runId; pipeline.id is the referenced pipeline definition. Using pipeline.id here makes the next Build API request target the definition ID rather than the selected wheel run, so the identity/build-number checks will reject the real release resource. Read runId for the wheel run and keep _WHEEL_PIPELINE_ID as the definition ID for the Runs API call.

    wheel_run_id = _positive_id(wheel_resource.get("pipeline", {}).get("id"))

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

[Copilot]

🟡 Changes recommended

Critical archive ownership bypass, incomplete archive reads, and dry-run plan mismatch remain unresolved.

Get a fresh assessment by requesting another Copilot review.

Review details

Suppressed comments (2)

OneBranchPipelines/conda-release-pipeline.yml:226

• This dry-run is not the exact production plan it claims to show: it prints an upload directly to the target label ($env:CONDA_LABEL), while conda-publish-step.yml uploads to main_staging_<BuildId> and then runs promote to add the public label and remove staging. A reviewer can therefore approve a plan that differs from the production mutations; print the generated staging label and the subsequent promotion/cleanup operations instead.

                      foreach ($p in ($pkgs | Sort-Object FullName)) {
                        $subdir = Split-Path -Leaf (Split-Path -Parent $p.FullName)
                        $sha256 = (Get-FileHash -LiteralPath $p.FullName -Algorithm SHA256).Hash.ToLowerInvariant()
                        Write-Host "  SHA256: $sha256  $subdir/$($p.Name)"
                        Write-Host "  WOULD RUN: anaconda upload --user $env:CONDA_CHANNEL --label $env:CONDA_LABEL --skip-existing  $subdir/$($p.Name)"

eng/conda_tools/archive.py:113

• _read_bytes only enforces an upper limit and stops on the first empty read; it never verifies that a TAR member's declared member.size was actually consumed. Consequently a truncated payload (or an info/index.json whose valid prefix ends before its declared size) can be returned as if it were complete. Pass the declared size through these TAR readers and reject short reads before yielding/parsing the member.

    reader = _LimitedReader(source, limit, description)
    with io.BytesIO() as result:
        while data := reader.read(_CHUNK_BYTES):
            result.write(data)
        return result.getvalue()

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

[Sumit Sarabhai (sumitmsft)]

Reviewed the PR for correctness, security, reliability, performance, test coverage, repository conventions, and applicable architecture and design specifications. No actionable issues were identified. The implementation is consistent with repository standards and the applicable approved design requirements.

The findings raised in earlier review rounds have been verified as resolved at this head:

• The dead CONDA_ALLOW_UNSIGNED_PATCH "assertion-only" guard and its misleading documentation have been removed.
• The Miniforge installer is now verified fail-closed against MINIFORGE_SHA256 (or the release's published .sha256 sidecar) before execution.
• Conda release provenance and publication checks are enforced.

Recommendation: Approve