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.

소스 정보

저장소
NVIDIA/multi-storage-client
최근 소스 활동
2026년 9월 9일 18:30
감지된 SKILL.md 언어
영어
스타
87
포크
28

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

파일 탐색기
2 개 파일

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
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)
GitHub에서 보기