Skip to content

docs: correct AGENTS.md release process to match actual PyPI environment config #130

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Bre77 merged 1 commit into from
Aug 22, 2026
Merged

docs: correct AGENTS.md release process to match actual PyPI environment config #130

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion AGENTS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -93,7 +93,7 @@ Scope flags on `TeslaFleetApi.__init__` control which submodules are instantiate

### Release Process

No release-please or version-bump automation. To ship: bump `version` in `pyproject.toml` and `__version__` in `tesla_fleet_api/__init__.py`, then run `uv lock` to regenerate `uv.lock` so its root package version matches, in a `Bump version to X.Y.Z` commit on `main`, then push a matching `vX.Y.Z` tag. CI (`ci.yml`) and the release gate (`release.yml`) run `uv sync --locked`, which fails the build if `uv.lock` doesn't match `pyproject.toml` — a version bump that skips `uv lock` is caught before merge/tag rather than shipping a stale lockfile. `.github/workflows/release.yml` triggers directly on that tag push: it reruns the full CI gate (ruff, pyright, pytest, `uv build` + `twine check`) on the exact tagged commit, then requires approval on the `pypi` GitHub environment (required reviewers configured via the Environments API — there's no repo Settings UI for it) before publishing via the PyPA OIDC trusted-publishing action (with PEP 740 attestations) and cutting the GitHub Release. It is a plain top-level workflow, not a `workflow_call` reusable one — the PyPI trusted publisher for this project is configured as workflow `release.yml` + environment `pypi`, and a reusable-workflow caller's signing identity doesn't match that publisher/attestation identity. Sibling repos each carry their own local copy of this workflow rather than calling it cross-repo.
No release-please or version-bump automation. To ship: bump `version` in `pyproject.toml` and `__version__` in `tesla_fleet_api/__init__.py`, then run `uv lock` to regenerate `uv.lock` so its root package version matches, in a `Bump version to X.Y.Z` commit on `main`, then push a matching `vX.Y.Z` tag. CI (`ci.yml`) and the release gate (`release.yml`) run `uv sync --locked`, which fails the build if `uv.lock` doesn't match `pyproject.toml` — a version bump that skips `uv lock` is caught before merge/tag rather than shipping a stale lockfile. `.github/workflows/release.yml` triggers directly on that tag push: it reruns the full CI gate (ruff, pyright, pytest, `uv build` + `twine check`) on the exact tagged commit, then publishes via the PyPA OIDC trusted-publishing action (with PEP 740 attestations) using the `pypi` GitHub environment and cuts the GitHub Release. The `pypi` environment has no protection rules (no required reviewers) — publishing is gated only by CI passing on the tagged commit, not by a manual approval step. Merging the PR that lands the version bump is the effective publish approval. It is a plain top-level workflow, not a `workflow_call` reusable one — the PyPI trusted publisher for this project is configured as workflow `release.yml` + environment `pypi`, and a reusable-workflow caller's signing identity doesn't match that publisher/attestation identity. Sibling repos each carry their own local copy of this workflow rather than calling it cross-repo.

### Error Handling

Expand Down
Loading