You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -15,6 +15,8 @@ We utilize a variety of tools to ensure smooth development, testing, and code qu
15
15
16
16
- Virtualenv: [Virtualenv](https://virtualenv.pypa.io/en/latest/) is leveraged by Tox to create isolated environments for each test suite, ensuring consistent dependencies and reducing conflicts.
17
17
18
+
- UV: [UV](https://docs.astral.sh/uv/) is a fast package manager that can manage Python versions, run and install Python packages, and be used instead of pip, virtualenv, and more.
19
+
18
20
- Pytest: [Pytest](https://docs.pytest.org/en/stable/) is the test framework we use for writing and running our unit tests. It supports fixtures, parameterized tests, and other features that make testing more powerful and flexible.
19
21
20
22
- Pylint: [Pylint](https://pylint.readthedocs.io/en/stable/) is used for code linting to enforce coding standards and catch potential issues early. Maintaining a consistent code style is important, and Pylint helps achieve that goal.
Copy file name to clipboardExpand all lines: doc/dev/mgmt/mgmt_release.md
+22-25Lines changed: 22 additions & 25 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,16 +2,16 @@
2
2
3
3
## General Release Process Overview
4
4
5
-
Once Swagger PR is merged, SDK automation will create pull request to Azure SDK for Python repository, and here are steps that you need to do in order to release a new package:
5
+
Once Swagger PR is merged and a release plan/request is submitted, here are steps that you need to do in order to release a new package:
6
6
7
-
-open PR that was merged in swagger repository and find the link to the PR createted in Azure SDK for Python
8
-
-reopen generated SDK PR and make sure the CI passes
7
+
-create SDK pull request with code generation
8
+
-identify and resolve breaking changes
9
9
- verify that generated code was generated correctly, make sure right version was generated with right configuration
10
+
- verify the release notes match actual changes (CHANGELOG.md)
11
+
- verify the version accordingly to changes that were made (_version.py)
12
+
- generate samples and develop tests
13
+
- make sure the CI passes
10
14
- merge the PR if everything looks good
11
-
- create another PR manually in order to add release notest and update version (this is currently not done by automation)
12
-
- generate release notes as described below, verify they match actual changes (HISTORY.rst)
13
-
- update version accordingly to changes that were made (version.py)
14
-
- merge the PR
15
15
- run release pipeline
16
16
17
17
Once you have a PR that contains accurate with correct tests (or no tests at all, but CI is green), this page explains how to prepare for a release.
@@ -20,8 +20,8 @@ IMPORTANT NOTE: All the commands in this page assumes you have loaded the [dev_s
20
20
21
21
## Manual generation
22
22
23
-
If the automation is not doing its job to create an auto PR, Python has a SwaggerToSdk CLI that can be used to generate a specific Readme. You need
24
-
a virtual environment loaded with at least `eng/tools/azure-sdk-tools` installed.
23
+
If the automation is not doing its job to create an auto PR, Python has a SwaggerToSdk CLI that can be used to generate SDK by a specific Readme. You need
24
+
a virtual environment loaded with at least `eng/tools/azure-sdk-tools` installed. And to manually create a package from Typespec, here's the full direction https://github.com/Azure/azure-sdk-for-python/wiki/Generate-Python-Mgmt-SDK-from-Typespec.
25
25
26
26
```shell
27
27
# Using default configuration (this can be a Github raw link)
@@ -43,16 +43,16 @@ If not, you can execute this command (replace the last part by your package name
If the file sdk_packaging.toml didn't exist, now one is created with default values. Update this file and update the default values to the one from this service. Once it's done, restart the same script.
46
+
If the file pyproject.toml didn't exist, now one is created with default values. Update this file and update the default values to the one from this service. Once it's done, restart the same script.
47
47
48
48
Your packaging info are up-to-date
49
49
50
50
## Building the ChangeLog
51
51
52
-
For all packages, you need to update the `HISTORY.rst` file
52
+
For all packages, you need to update the `CHANGELOG.md` file
53
53
54
54
```
55
-
/azure-mgmt-myservice/HISTORY.rst
55
+
/azure-mgmt-myservice/CHANGELOG.md
56
56
```
57
57
58
58
For all **autorest generated packages**, there is a tool that allows you to auto-build the ChangeLog.
As part of shipping SDKs that can be trusted by customers, the azure-sdk-for-python dev team maintains a suite of `checks` that can be utilized by developers to ensure predictable quality measures. These checks help determine whether a package meets the required quality standards for release or needs further work before it can be shipped. These `checks` are implemented in a single entrypoint within the local development package `eng/tools/azure-sdk-tools`. This package provides:
4
+
5
+
- Templated package generation for mgmt packages
6
+
- The test-framework that all packages within this monorepo use (including record/playback integration)
7
+
- A ton of CI related tasks and boilerplate
8
+
- Static analysis code
9
+
10
+
A `tool` in this context is merely a single entrypoint provided by the `azpysdk` entrypoint in the `eng/tools/azure-sdk-tools` package.
11
+
12
+
## Available Tools
13
+
14
+
This repo is currently migrating all checks from a slower `tox`-based framework, to a lightweight implementation that uses `asyncio` to simultaneously run checks. This tools list is the current set that has been migrated from `tox` to the `azpysdk` entrypoint.
15
+
16
+
|tool|description|invocation|
17
+
|---|---|---|
18
+
|`pylint`| Runs `pylint` checks or `next-pylint` checks. (based on presence of `--next` argument) |`azpysdk pylint .`|
19
+
|`mypy`| Runs `mypy` checks or `next-mypy` checks. (based on presence of `--next` argument) |`azpysdk mypy --next=True .`|
20
+
|`sphinx`| Generates a documentation website for the targeted packages. Runs `sphinx` or `next-sphinx` (based on presence of `--next` argument). |`azpysdk sphinx .`|
21
+
|`pyright`| Runs `pyright` checks or `next-pyright` checks. (based on presence of `--next` argument) |`azpysdk pyright .`|
22
+
|`black`| Runs `black` checks. |`azpysdk black .`|
|`import_all`| Installs the package w/ default dependencies, then attempts to `import *` from the base namespace. Ensures that all imports will resolve after a base install and import. |`azpysdk import_all .`|
26
+
27
+
## Common arguments
28
+
29
+
### Globbing
30
+
The azpysdk is intended to be used from within the azure-sdk-for-python repository. A user can invoke
31
+
32
+
```
33
+
/azure-sdk-for-python/> azpysdk import_all azure-storage* # will run import_all for all packages starting with `azure-storage`
34
+
35
+
/azure-sdk-for-python/> azpysdk import_all azure-storage-blob,azure-core # invoke import_all for two packages
36
+
37
+
/azure-sdk-for-python/sdk/core/azure-core/> azpysdk import_all . # invoke import_all for the local package only
38
+
```
39
+
40
+
### Automatically isolating the environment
41
+
42
+
The targeted tool should be able to run in an isolated environment for a couple reasons:
43
+
- When attempting to diagnose an issue, sometimes a user is best served by completely wiping their `venv` and starting over from scratch. Issues may stem from having additional deps downloaded that normally wouldn't be installed with the package.
44
+
- In `CI`, we _have_ to run in isolated virtual environments for some checks to allow processes like `multiple pytest` runs to invoke without accidentally stomping on each other's progress or hitting file contention errors. CI passes this flag by default from `dispatch_checks.py`.
45
+
46
+
To utilize this feature, add `--isolate` to any `azpysdk` invocation:
# will install and run within a venv in `sdk/storage/azure-storage-blob/.venv_import_all/
51
+
```
52
+
53
+
## Prerequisite
54
+
55
+
- You need to have Python installed
56
+
- The monorepo requires a minimum of `python 3.9`, but `>=3.11` is required for the `sphinx` check due to compatibility constraints with external processes.
57
+
- You may optionally use the ["uv"](https://docs.astral.sh/uv/) tool, which is fast and handles Python version and venv creation automatically.
58
+
59
+
## Initial setup
60
+
61
+
- Go to the folder of the package you're working on, for instance `sdk/contoso/azure-contoso`
62
+
63
+
### Setup with uv
64
+
65
+
`uv venv`
66
+
67
+
```bash
68
+
# for WSL
69
+
source .venv/bin/activate
70
+
71
+
# for Windows
72
+
.venv\Scripts\activate
73
+
```
74
+
75
+
`uv pip install -r dev_requirements.txt`
76
+
77
+
### Setup with pip/python
78
+
79
+
`python -m venv .venv`
80
+
81
+
```bash
82
+
# for WSL
83
+
source .venv/bin/activate
84
+
85
+
# for Windows
86
+
.venv\Scripts\activate
87
+
```
88
+
89
+
`pip install -r dev_requirements.txt`
90
+
91
+
## Using the CLI
92
+
93
+
```bash
94
+
# You can call the command directly if you activated the venv
95
+
azpysdk <tool_name>
96
+
```
97
+
98
+
## Advanced scenario
99
+
100
+
### Using different Python version
101
+
102
+
You can locally test different Python versions to check compatibility with all the required Python versions.
103
+
104
+
Note that this is optional, and you can rely on CI to test python versions.
105
+
106
+
#### With uv
107
+
108
+
You can specify a Python version upon venv creation:
109
+
`uv venv --python 3.11`
110
+
111
+
#### With Python
112
+
113
+
You need to install [pyenv](https://github.com/pyenv/pyenv?tab=readme-ov-file#installation), which lets you easily switch between multiple versions of Python.
Copy file name to clipboardExpand all lines: eng/common/instructions/azsdk-tools/create-release-plan.instructions.md
+6-1Lines changed: 6 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,10 @@
1
+
> **Important Note for LLM**
2
+
> Backend processes may use Azure DevOps work item data as needed. However, do **not** mention or display the work item link/URL, or any reference to Azure DevOps work item resources directly in conversation with the user.
3
+
> All manual updates to an existing release plan must be made through the [Release Planner Tool](https://aka.ms/sdk-release-planner) to ensure proper tracking and validation.
4
+
> Only provide release plan details such as **Release Plan Link** and **Release Plan ID** to the user
5
+
1
6
# Release Plan Creation Process
2
-
You goal is to create a valid release plan. You must prompt user to provide all required information and all input must match the format and requirement mentioned in step 3 below.
7
+
Your goal is to create a valid release plan. You must prompt user to provide all required information and all input must match the format and requirement mentioned in step 3 below.
3
8
Follow these steps in order to create or manage a release plan for an API specification pull request:
0 commit comments