Conda Release 2026.03.01 generated by 5815160#44922
Conda Release 2026.03.01 generated by 5815160#44922azure-sdk wants to merge 99 commits intoAzure:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
This PR automates and streamlines the quarterly Conda release process for the Python SDK, wiring in a scheduled pipeline, shared helper functions, and a script to update Conda artifacts, recipes, and release logs in a single flow.
Changes:
- Adds a new
conda-update-pipeline.ymlpipeline that runs on a schedule (or manually) to executeconda/update_conda_files.py, bump the Conda release version, updateconda-sdk-client.yml, and open a PR with the generated changes. - Introduces
conda/update_conda_files.pyandconda/conda_helper_functions.pyto pull package metadata from the central CSV and PyPI, detect new/outdated packages, update Conda configuration (YAML/meta.yaml), and maintain Conda release logs (including bundle-aware handling). - Enhances tooling to support Conda bundle metadata (
[tool.azure-sdk-conda]inpyproject.tomlandParsedSetup.get_conda_config/is_stable_release), and updates Conda recipes, management-meta imports, and release logs to the 2026.03.01 release snapshot.
Reviewed changes
Copilot reviewed 52 out of 52 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
sdk/keyvault/azure-keyvault-keys/pyproject.toml |
Moves the [tool.azure-sdk-conda] section next to build tooling configuration, keeping bundle metadata close to other tooling settings for azure-keyvault. |
sdk/communication/azure-communication-identity/pyproject.toml |
Reorders [tool.azure-sdk-conda] and pytest config so Conda bundle metadata for azure-communication is grouped with other tool config. |
eng/tools/azure-sdk-tools/ci_tools/parsing/parse_functions.py |
Extends ParsedSetup with get_conda_config() and is_stable_release() and adds get_conda_config / classify_release_type helpers so Conda-related metadata can be read from pyproject.toml. |
eng/pipelines/templates/stages/conda-sdk-client.yml |
Normalizes YAML style, updates specific package versions, and adds/updates management packages in the CondaArtifacts list to reflect the 2026.03.01 release. |
eng/pipelines/conda-update-pipeline.yml |
New scheduled pipeline that prepares the environment, runs conda/update_conda_files.py with an auto- or parameter-derived release date, and (optionally) creates a PR pre-populated with standard Conda-release instructions. |
conda/update_conda_files.py |
New orchestrator script that bumps AZURESDK_CONDA_VERSION, computes new/outdated packages from the CSV, updates conda-sdk-client.yml, creates meta.yamls for new data-plane packages, updates azure-mgmt meta.yaml and all Conda release logs, and prints a summary of items needing manual follow-up. |
conda/conda_helper_functions.py |
New helper module to download/parse the central python-packages.csv, classify mgmt vs data-plane, determine whether a package is new/out-of-date, discover SDK paths and bundles, build Conda artifact indices, and pull PyPI version/download URLs. |
conda/conda-releaselogs/*.md |
Adds a new ## 2026.03.01 section (and in one case updates an existing entry) across many data-plane and mgmt release logs to record which package versions are included in the 2026.03.01 Conda release. |
conda/conda-recipes/conda_env.yml |
Bumps AZURESDK_CONDA_VERSION from 2025.12.01 to 2026.03.01 to represent the new Conda release label. |
conda/conda-recipes/azure-mgmt/meta.yaml |
Adjusts the test: imports list to fix module path typos, add new azure-mgmt-* management packages, and keep the import set aligned with the updated azure-mgmt bundle contents. |
| else: | ||
| release_log_path = os.path.join( | ||
| CONDA_RELEASE_LOGS_DIR, f"{package_name}.md" | ||
| ) | ||
| bundle_name = package_name # for release log logic below |
There was a problem hiding this comment.
In this branch, bundle_name is reset to package_name for non-bundled libraries, but later in the function the logic that builds pkg_updates checks if bundle_name: to decide whether to treat the entry as a bundle vs. a single-package release. Because bundle_name is always a non-empty string after this assignment, the single-package code path is effectively unreachable and new non-bundled packages will end up with empty or incomplete "Packages included" sections in their release logs. Consider keeping a separate variable for the log file name (e.g. log_name) or only treating bundle_name as truthy when it actually represents a bundle key present in bundle_map, so that standalone packages correctly add their own - {package_name}-{version} entry.
This PR was automatically generated to update Conda files for a new release.
Next Steps