CHORE: Release Manager agent for release automation#545
CHORE: Release Manager agent for release automation#545gargsaumya wants to merge 2 commits intomainfrom
Conversation
gargsaumya
changed the title
There was a problem hiding this comment.
Pull request overview
Adds a new GitHub Copilot agent definition to standardize and automate the end-to-end mssql-python release workflow spanning GitHub and Azure DevOps.
Changes:
- Introduces a “Release Manager” agent with a prescribed 9-step release sequence and checklist.
- Documents automated Rust (
mssql_py_core) change resolution for release notes, with a GitHub Models fallback. - Provides guidance for ADO cherry-pick/PR flow, pipeline execution, artifact verification, rollback, and smoke testing.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| ``` | ||
| 4. Extract the `## Rust Changes` section from each matching PR body — use this content directly. | ||
|
|
||
| **Fallback** (if no `## Rust Changes` section exists): query `mssql-rs` commits between the two `"Bump mssql-py-core to X.X.X"` SHAs, send them to GitHub Models asking which are customer-facing, then ask the user to confirm the AI-generated entries. |
There was a problem hiding this comment.
The GitHub Models fallback says to "send them to GitHub Models" but doesn’t specify the endpoint/model or note that workflows need models: read permission. Since this repo already standardizes on https://models.github.ai/inference/chat/completions with model openai/gpt-4.1, consider documenting the exact call pattern (and required permission) here so the fallback is actionable and consistent.
| **Fallback** (if no `## Rust Changes` section exists): query `mssql-rs` commits between the two `"Bump mssql-py-core to X.X.X"` SHAs, send them to GitHub Models asking which are customer-facing, then ask the user to confirm the AI-generated entries. | |
| **Fallback** (if no `## Rust Changes` section exists): query `mssql-rs` commits between the two `"Bump mssql-py-core to X.X.X"` SHAs, then send those commits to GitHub Models using the repo-standard chat completions endpoint `https://models.github.ai/inference/chat/completions` with model `openai/gpt-4.1`, asking it to identify which changes are customer-facing and to draft release-note bullets. If this is run from a workflow, ensure the workflow has `models: read` permission. After generating the entries, ask the user to confirm the AI-generated results before adding them to the release notes. |
| ``` | ||
| 4. Extract the `## Rust Changes` section from each matching PR body — use this content directly. | ||
|
|
||
| **Fallback** (if no `## Rust Changes` section exists): query `mssql-rs` commits between the two `"Bump mssql-py-core to X.X.X"` SHAs, send them to GitHub Models asking which are customer-facing, then ask the user to confirm the AI-generated entries. |
There was a problem hiding this comment.
In the Rust fallback, "commits between the two "Bump mssql-py-core to X.X.X" SHAs" is ambiguous: those PR titles reference versions, not SHAs, and it’s unclear how the agent should determine the start/end commit boundaries. Please clarify whether the boundaries are the merge commits of the two bump PRs, tags in mssql-rs, or something else, and how to obtain them deterministically.
| **Fallback** (if no `## Rust Changes` section exists): query `mssql-rs` commits between the two `"Bump mssql-py-core to X.X.X"` SHAs, send them to GitHub Models asking which are customer-facing, then ask the user to confirm the AI-generated entries. | |
| **Fallback** (if no `## Rust Changes` section exists): do **not** use the bump-PR merge commits in `mssql-python` as boundaries. Instead, use the versions from steps 1-2 as the source of truth, resolve them in `microsoft/mssql-rs` to Git tags named either `v<version>` or `<version>`, and diff the commits between those two resolved `mssql-rs` tags. Send that commit list to GitHub Models asking which changes are customer-facing, then ask the user to confirm the AI-generated entries. If either version cannot be resolved to an `mssql-rs` tag in one of those two exact forms, stop and ask the user for the exact `mssql-rs` start/end commits rather than guessing. |
| smoke_test_env/Scripts/activate # Windows: smoke_test_env\Scripts\activate | ||
| pip install mssql-python==X.X.X | ||
| python -c "import mssql_python; print(mssql_python.__version__)" |
There was a problem hiding this comment.
The smoke-test venv activation path shown (smoke_test_env/Scripts/activate) is Windows-specific; on macOS/Linux it should be smoke_test_env/bin/activate. As written, following these instructions on non-Windows will fail—please include both platform paths (or use a platform-agnostic approach like invoking the venv’s python directly).
| smoke_test_env/Scripts/activate # Windows: smoke_test_env\Scripts\activate | |
| pip install mssql-python==X.X.X | |
| python -c "import mssql_python; print(mssql_python.__version__)" | |
| # Windows: | |
| smoke_test_env\Scripts\python -m pip install mssql-python==X.X.X | |
| smoke_test_env\Scripts\python -c "import mssql_python; print(mssql_python.__version__)" | |
| # macOS/Linux: | |
| smoke_test_env/bin/python -m pip install mssql-python==X.X.X | |
| smoke_test_env/bin/python -c "import mssql_python; print(mssql_python.__version__)" |
| This uses Maven ContentType, not PyPI. **Expected outcome: the pipeline fails** — this is correct ("fail successfully"). | ||
|
|
||
| > ⚠️ **MANUAL**: Ask user to confirm the dummy pipeline completed with the expected failure. |
There was a problem hiding this comment.
Step 6 states the dummy release pipeline is expected to fail ("fail successfully"), but the repo’s OneBranchPipelines/dummy-release-pipeline.yml is written as a successful test release (it even prints "DUMMY RELEASE COMPLETED" and doesn’t intentionally fail). Treating failure as success here could mask real problems—please align the instructions with the pipeline’s intended outcome (likely: pipeline should complete successfully while publishing to Maven, not PyPI).
| This uses Maven ContentType, not PyPI. **Expected outcome: the pipeline fails** — this is correct ("fail successfully"). | |
| > ⚠️ **MANUAL**: Ask user to confirm the dummy pipeline completed with the expected failure. | |
| This uses Maven ContentType, not PyPI. **Expected outcome: the pipeline completes successfully** as a test release validation. | |
| > ⚠️ **MANUAL**: Ask user to confirm the dummy pipeline completed successfully. If it fails, halt and investigate before proceeding. |
📊 Code Coverage Report
Diff CoverageDiff: main...HEAD, staged and unstaged changesNo lines with coverage information in this diff. 📋 Files Needing Attention📉 Files with overall lowest coverage (click to expand)mssql_python.pybind.logger_bridge.cpp: 59.2%
mssql_python.pybind.ddbc_bindings.h: 67.8%
mssql_python.row.py: 70.5%
mssql_python.pybind.logger_bridge.hpp: 70.8%
mssql_python.pybind.ddbc_bindings.cpp: 74.5%
mssql_python.pybind.connection.connection.cpp: 75.8%
mssql_python.__init__.py: 77.3%
mssql_python.ddbc_bindings.py: 79.6%
mssql_python.pybind.connection.connection_pool.cpp: 79.6%
mssql_python.connection.py: 85.3%🔗 Quick Links
|
gargsaumya
changed the title
Work Item / Issue Reference
Summary
This pull request adds a comprehensive release manager agent specification for the
mssql-pythonproject. The new agent automates and documents the entire release process, including integration with GitHub and Azure DevOps, step-by-step instructions, and detailed guidance for handling Rust dependencies and release notes.The most important changes are:
Release Process Automation and Guidance
.github/agents/release-manager.agent.md, which defines the Release Manager agent formssql-python, detailing a strict, step-by-step workflow for releases, including both automated and manual steps, and specifying required tools and user prompts.Rust Dependency Handling
mssql_py_coreversion bumps, ensuring these are included in release notes with proper attribution and PR links.Release Notes and Checklist
Rollback and Recovery Procedures