Skip to content

Conversation

@amber-Chen-86
Copy link

Description

Please add an informative description that covers that changes made by the pull request and link all relevant issues.

If an SDK is being regenerated based on a new API spec, a link to the pull request containing these API spec changes should be included above.

All SDK Contribution checklist:

  • The pull request does not introduce [breaking changes]
  • CHANGELOG is updated for new features, bug fixes or other significant changes.
  • I have read the contribution guidelines.

General Guidelines and Best Practices

  • Title of the pull request is clear and informative.
  • There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

  • Pull request includes test coverage for the included changes.

kashish2508 and others added 7 commits September 9, 2025 12:19
…e#42867)

* docs(playwrighttesting): Readme update with deprecation message

* Deprecation update

* date update

* deprecation date update

* changelog date

---------

Co-authored-by: guptakashish <[email protected]>
* fix automatic inference of dtypes

* Fix inference of dtypes

* updates
…ing` settings (Azure#42862)

* update build_package function (heavily used by create_package_and_install) to be much less verbose by default. We do not see to see
  all build output for every package when it's just standard  assembly. we have verify_sdist and verify_whl, and beyond that devs should validate
  the contents of their packages.
* in error cases, we should still see error output, but otherwise, users will have to set LOG_LEVEL environment variable at runtime to see the raw build logs

---------

Co-authored-by: Copilot <[email protected]>
Co-authored-by: McCoy Patiño <[email protected]>
* initial black script

* clean

* typo

* add check=true

* use install_into_venv

* refactor install_into_venv, use in pylint

* replace pip in sphinx

* refactor install_into_venv, removing extras and editable args

* add log to black

* replace pip in whl
* fixing mypy issues

* running the autorest

* fixing the mypy errors

* fixing mypy error

* reverting the shared model code change for the mypy

* fixing some of issues

* reverting target participant change in the  create call

* supressing few of mypy error

* fixing the testing issue

* updated

* fixing the pylint

* Updating the changelog and ga version

* removed

* fixing my py errors

* addressing the mypy errors

* removing the changes which added by mistake

* resolving the comments

* fixing the issue

* pushing the changes related to communication identifier return type

* reverting ignore type

* removing few of the arg type

* Mypy fixes

* Fix tests

* Updated changelog

* Added missing models to init

* Fix docstring

---------

Co-authored-by: antisch <[email protected]>
…/tspconfig.yaml', API Version: 2025-05-15-preview, SDK Release Type: beta, and CommitSHA: '261adc4ae25d7e639c4e13a1d63f0301e137c79d' in SpecRepo: 'https://github.com/Azure/azure-rest-api-specs' Pipeline run: https://dev.azure.com/azure-sdk/internal/_build/results?buildId=5314004 Refer to https://eng.ms/docs/products/azure-developer-experience/develop/sdk-release/sdk-release-prerequisites to prepare for SDK release.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants