|
| 1 | +# `codetracer-python-recorder` Release Operations |
| 2 | + |
| 3 | +This note supplements the release checklist with details about the automated workflow, |
| 4 | +Trusted Publishing setup, and manual approvals required to promote artefacts from |
| 5 | +TestPyPI to PyPI. |
| 6 | + |
| 7 | +## GitHub Actions workflow |
| 8 | + |
| 9 | +- Workflow file: `.github/workflows/recorder-release.yml`. |
| 10 | +- Triggers: |
| 11 | + - `workflow_dispatch` – run a staged release without creating a tag. Supply the |
| 12 | + target ref (branch/tag) and monitor the jobs; artefacts are still produced but |
| 13 | + PyPI promotion is skipped unless the ref is a tagged release. |
| 14 | + - `push` to tags matching `recorder-v*`. |
| 15 | +- Job sequence: |
| 16 | + 1. `verify` (ubuntu) – prepares the dev environment via Nix, runs `just test`, |
| 17 | + and confirms Python/Rust version parity. |
| 18 | + 2. `build` matrix (linux-x86_64, linux-aarch64, macos-universal2, windows-amd64) – |
| 19 | + uses maturin to build wheels (and the sdist on linux-x86_64) and uploads artefacts. |
| 20 | + 3. `publish-testpypi` – aggregates artefacts, performs a Linux smoke install using |
| 21 | + `scripts/select_recorder_artifact.py`, then publishes to TestPyPI. |
| 22 | + 4. `publish-pypi` – gated behind the protected environment. Runs only for tag pushes |
| 23 | + after manual approval, reusing artefacts from earlier jobs. |
| 24 | + |
| 25 | +## Trusted Publishing configuration |
| 26 | + |
| 27 | +- TestPyPI and PyPI both list `metacraft-labs/cpr-main` as a Trusted Publisher. |
| 28 | +- The workflow requests OIDC tokens automatically; no API tokens are stored in secrets. |
| 29 | +- GitHub environments: |
| 30 | + - `testpypi` – no approval required; used to track audit logs and enforce environment |
| 31 | + level variables if needed. |
| 32 | + - `pypi-production` – requires manual approval by a Release Engineer before the |
| 33 | + `publish-pypi` job starts. Approvers can approve directly from the workflow run UI. |
| 34 | + |
| 35 | +## Maintainer checklist highlights |
| 36 | + |
| 37 | +1. **Before dispatching the workflow** |
| 38 | + - Update version numbers in `pyproject.toml` and `Cargo.toml`. |
| 39 | + - Append a section to `codetracer-python-recorder/CHANGELOG.md`. |
| 40 | + - Ensure `python3 scripts/check_recorder_version.py` succeeds. |
| 41 | + - Optionally run `just smoke-wheel` locally. |
| 42 | + |
| 43 | +2. **Running the workflow** |
| 44 | + - For dry runs (no tagging yet) use `workflow_dispatch` targeting the release branch. |
| 45 | + - For real releases, push the annotated tag (`recorder-vX.Y.Z`). The workflow validates |
| 46 | + the tag against the pyproject version. |
| 47 | + |
| 48 | +3. **Approvals** |
| 49 | + - Watch the `publish-testpypi` job; ensure the smoke install step passes. |
| 50 | + - Approve the `pypi-production` environment to trigger promotion. Include a note in the |
| 51 | + approval dialog referencing the TestPyPI run result. |
| 52 | + |
| 53 | +4. **Post-release** |
| 54 | + - Install from PyPI on Linux/macOS/Windows for Python 3.12 and 3.13 |
| 55 | + (`pip install codetracer-python-recorder && python -m codetracer_python_recorder --help`). |
| 56 | + - Publish GitHub release notes that link back to the changelog entry. |
| 57 | + - Close the release tracker issue once validation is complete. |
| 58 | + |
| 59 | +## Fallback procedure |
| 60 | + |
| 61 | +If the workflow cannot obtain an OIDC token (e.g., PyPI incidents): |
| 62 | + |
| 63 | +1. Temporarily disable the Trusted Publishing requirement in PyPI/TestPyPI. |
| 64 | +2. Configure a scoped API token as an environment secret and rerun the failed publish job. |
| 65 | +3. Re-enable Trusted Publishing immediately after resolving the incident. |
| 66 | +4. Document the incident in the release tracker issue. |
0 commit comments