{CI} Support pyproject.toml builds and add migration guide

[aryasadeghi1]

🤖 PR Validation — ️✔️ All clear

Breaking Changes
️✔️ None

Build with python -m build and accept either pyproject.toml or setup.py, so extensions can migrate one at a time. Nothing is migrated here.

test_source.py silently skipped extensions that had no setup.py; it now fails. It also no longer runs the build with cwd inside the extension, where the build/ dir shadows the build module and breaks every run after the first.

sdist from build_package.py is now .tar.gz instead of .zip, since PEP 517 has no zip option.

Built all 210 extensions locally to check this.

---

This checklist is used to make sure that common guidelines for a pull request are followed.

Related command

General Guidelines

• Have you run azdev style <YOUR_EXT> locally? (pip install azdev required)
• Have you run python scripts/ci/test_index.py -q locally? (pip install azdev required)
• My extension version conforms to the Extension version schema

For new extensions:

• My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish

There is a pipeline to automatically build, upload and publish extension wheels.
Once your pull request is merged into main branch, a new pull request will be created to update src/index.json automatically.
You only need to update the version information in file setup.py and historical information in file HISTORY.rst in your PR but do not modify src/index.json.

[azure-client-tools-bot-prd]

Hi aryasadeghi1,
Please write the description of changes which can be perceived by customers into HISTORY.rst.
If you want to release a new extension version, please update the version in setup.py as well.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Aditya Pujara (a0x1ab)]

/azp run

[Copilot]

Pull request overview

Updates CI and automation packaging flows to support PEP 517 builds (python -m build) so extensions can migrate from setup.py to pyproject.toml incrementally, and adds a migration guide for extension owners.

Changes:

• Switch CI/automation wheel building to python -m build, allowing either pyproject.toml or legacy setup.py.
• Tighten CI validation by failing extensions that have neither build file, and improve build error output.
• Pin CI tooling (azdev==0.2.13) and add documentation to guide extension migration.

Reviewed changes

Copilot reviewed 10 out of 11 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
scripts/ci/test_source.py	Builds wheels via python -m build (no cwd shadowing), validates build files exist, and improves error reporting.
scripts/ci/azdev_linter_style.py	Updates checks/error messaging to accept pyproject.toml during migration.
scripts/automation/build_package.py	Builds wheel+sdist via PEP 517 (python -m build) and supports either build definition file.
docs/README.md	Adds link to the new pyproject migration guide.
docs/pyproject-migration.md	Adds a migration guide and recommended pyproject.toml template/mapping notes.
azure-pipelines.yml	Pins azdev to 0.2.13 in ADO pipelines.
.gitignore	Ignores .migration_tmp/ artifacts.
.github/workflows/VersionCalPRComment.yml	Pins azdev to 0.2.13 in GitHub Actions workflow.
.github/azure-client-tools-bot/config.yml	Adds pyproject.toml to required-change checks and updates guidance text.
.github/actions/env-setup/action.yml	Pins azdev to 0.2.13 in shared action.
.azure-pipelines/templates/azdev_setup.yml	Pins azdev and installs build/wheel needed for PEP 517 builds.

---

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

[azure-pipelines]

Azure Pipelines:
Successfully started running 2 pipeline(s).

[Ethan Yang (necusjz)]

elegant work!