Skip to main content

release-automation

Prepares and automates the release process for multi-storage-client (version bump, release notes, checklist). Use when the user wants to cut a release, bump version, prepare release, publish a new version, or automate release steps.

Datos de origen

Repositorio
NVIDIA/multi-storage-client
Última actividad en el origen
9 de septiembre de 2026 a las 18:30
Idioma detectado de SKILL.md
inglés
Estrellas
87
Forks
28

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Explorador de archivos
2 archivos

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
release-automation
description
Prepares and automates the release process for multi-storage-client (version bump, release notes, checklist). Use when the user wants to cut a release, bump version, prepare release, publish a new version, or automate release steps.
# Release Automation Guides the agent through preparing a release for the multi-storage-client repository. Tagging is done by the pipeline after the release MR is merged; this skill covers only the in-repo changes (version bump, release notes). Do not ask the user to run `git tag` or push a tag. ## When to Use - User asks to "cut a release", "bump version", "prepare release", "publish new version", or "automate release". - User wants to move unreleased notes into a versioned file and bump the package version. ## Prerequisites - Work from repository root. - Ensure `.release_notes/.unreleased.md` has been updated with notable changes (per PR template). If empty or placeholder-only, confirm with the user before releasing. ## Release Preparation Workflow ### 1. Determine the new version - Read current version from `multi-storage-client/pyproject.toml` (`version = "X.Y.Z"`). - If the user specified a version (e.g. "0.44.0"), use it. Otherwise propose: - **Patch** (e.g. 0.43.0 → 0.43.1): bug fixes only. - **Minor** (e.g. 0.43.0 → 0.44.0): new features, backward-compatible. - **Major**: breaking changes (rare; confirm with user). ### 2. Bump package version - In `multi-storage-client/pyproject.toml`, set `version = "<new_version>"` (e.g. `"0.44.0"`). ### 3. Finalize release notes - Read `.release_notes/.unreleased.md`. - Read git history for changes since the last release: `git log <previous_version>..HEAD --no-merges --format='%h %s%n%b'` (tags are unprefixed, e.g. `0.42.0` not `v0.42.0`). Use this to find and add relevant entries; omit CI/CD, build, and chore-only commits. - Create `.release_notes/<new_version>.md` with that content (e.g. `.release_notes/0.44.0.md`). Preserve structure (Breaking Changes, New Features, Bug Fixes, etc.). - Skip mentioning any changes that are CI/CD related. - Reset `.release_notes/.unreleased.md` to its template (with `<!-- Add items here. -->` at the top). If unsure whether the repo convention expects a reset, ask the user before modifying. ### 4. Verification (recommended) - Run `just build` from repo root (runs analyze, unit tests, ray tests; in CI also runs package). ### 5. Handoff checklist Present a short checklist for the user: - [ ] Version bumped in `multi-storage-client/pyproject.toml`. - [ ] `.release_notes/<new_version>.md` created; `.release_notes/.unreleased.md` handled as above. - [ ] `just build` passed (or user will run locally). - [ ] Create a git commit with the release changes and open/merge an MR; the pipeline will create and push the tag after merge. ## Reference - Repo-specific paths and CI details: [reference.md](reference.md)
Ver en GitHub