본문으로 건너뛰기
cccskills
무료GitHub에 공개

release-captain

Run the weekly OpenShell release captain checklist. Monday checks the pre-release train, triages failures and the compatibility review, and drafts the coordination post. Tuesday promotes the qualified pre-release after approval, verifies publication, and starts the next train. Trigger keywords - release captain, weekly release, Tuesday release, cut the release, release checklist, pre-release status, release train, start next train, stable release.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

연동 도구SlackGitHub
설치 방법 보기

포함된 파일(1)

  • SKILL.md10.2 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Release Captain

OpenShell publishes a stable release every Tuesday from a qualified pre-release (RFC 0014). The release captain keeps the week's pre-release train green, coordinates the last merges, cuts the release, and starts the next train.

How to use this skill

WhenAskWhat happens
The week before your turn"I'm release captain next week. Is the train ready?"Checks that the next version's -pre.1 exists. If not, ask this week's captain to start the train (Tuesday step 6). Then check each weekday that Auto-Tag's pre-release ran and passed (gh run list --workflow release-prerelease.yml --limit 3), and fix failures as they happen (Monday step 3) instead of on Monday.
Monday"Run the release captain Monday checklist."Monday steps 1–4.
A pre-release failed"vX.Y.Z-pre.N failed, help me fix it."Monday step 3 and Recovery.
Tuesday"Cut the release."Tuesday steps 1–6, ending with starting the next train.

Guardrails

Get explicit approval, with the exact command and target SHA, before pushing a tag, dispatching, rerunning, or cancelling a workflow, merging or approving a PR, or posting in Slack or GitHub. Never repoint a stable tag, delete a -pre.N tag, or start a second Pre-release run for a tag; it has no concurrency guard.

How the train works

  • A train has one base version, such as v0.1.4, fixed by its -pre.1 tag. A patch train can't take breaking changes to Stable interfaces.
  • Release Auto-Tag runs on weekdays at 14:00 Europe/Zurich. If main has commits since the latest -pre.N, it tags the next one and dispatches Pre-release (release-prerelease.yml, about 45 minutes). It skips when the train has no -pre.1 or the base version is already stable.
  • Pre-release builds, then publishes and qualifies in parallel, and writes a release-notes preview artifact. Pushing a -pre.N tag by hand starts it.
  • Release (release.yml) is dispatched by hand with the stable version. It picks the highest -pre.N on main whose whole Pre-release run passed, creates the stable tag on that commit, and publishes without requalifying.

Setup

export GH_REPO=NVIDIA/OpenShell
git fetch origin main --tags --force
PREV=$(git tag -l 'v*' --sort=-v:refname | grep -E '^v[0-9]+\.[0-9]+\.[0-9]+$' | head -1)
git tag -l 'v*' --sort=-v:refname | grep -E -- '-pre\.[0-9]+$' | head -5

Find the Pre-release run for a tag. A tag pushed by hand runs on the tag; an Auto-Tag run is dispatched on main:

TAG=vX.Y.Z-pre.N
gh run list --workflow release-prerelease.yml --branch "$TAG"
gh run list --workflow release-prerelease.yml --event workflow_dispatch --commit "$(git rev-parse "$TAG^{commit}")"

Preview the candidate Release would promote, read-only:

VERSION=vX.Y.Z
wt=$(mktemp -d)
git worktree add -q --detach "$wt" origin/main
(cd "$wt" && GITHUB_REPOSITORY=NVIDIA/OpenShell uv run -q --no-project python tasks/scripts/select-release-candidate.py "$VERSION" --branch main | jq .)
git worktree remove --force "$wt"

Monday: pre-flight

  1. Check the candidate. Run the preview. If the latest -pre.N isn't the candidate, its run failed; read why:

    RUN=<run-id>
    gh run view "$RUN" --json jobs --jq '.jobs[] | select(.conclusion == "failure" or .conclusion == "timed_out") | "\(.name)\t\(.url)"'
    gh run view "$RUN" --log-failed
    

    If the next version has no -pre.1, start the train (Tuesday step 6).

  2. Triage the compatibility review for the candidate's run. It's advisory, and a green job doesn't mean it found no breaks:

    ATTEMPT=$(gh run view "$RUN" --json attempt --jq .attempt)
    dir=$(mktemp -d)
    gh run download "$RUN" -n "compatibility-review-run-$RUN-attempt-$ATTEMPT" -D "$dir"
    jq '{status, verdict: .review.verdict}' "$dir/report.json"
    cat "$dir/report.md"
    

    Only complete with no_unaddressed_breaks is clean. A real break needs a fix, a revert, a minor train, or a maintainer-approved exception with upgrade steps in the release notes.

  3. Fix forward. A failed pre-release doesn't end the train. Find the cause, and let the failed run finish rather than cancelling it.

    A rerun repeats the same commit and workflow, so it only helps with a transient failure (see Recovery). Anything that needs a code or workflow fix ships in a new number: that -pre.N stays failed, and Release skips it. Merge the fix, then cut the next -pre.N from the tip of main after approval:

    gh workflow run release-auto-tag.yml --ref main
    

    Tag a specific commit by hand (as in Tuesday step 6) only when the tip of main isn't the commit you want.

  4. Draft the coordination post. Start a thread in the OpenShell channel of the CNCF Slack. The release ships from main with no release branch, so the thread is for getting ready PRs reviewed and merged before the cutoff. List approved PRs:

    gh pr list --base main --state open --search "review:approved" --json number,title,author --jq '.[] | "#\(.number) \(.title) (@\(.author.login))"'
    

    The release ships the final pre-release's commit, if it passes. Pick a cutoff before Tuesday's Auto-Tag run, or a later one after which you tag the final pre-release by hand. Don't promise that everything merged by the cutoff ships, or name the next version.

    :thread: OpenShell vX.Y.Z release, Tuesday <date>. I'm release captain this week.
    
    Status: vX.Y.Z-pre.N (<commit>) passed qualification. <blockers and owners, or "No blockers.">
    
    Reply here with any ready PRs you'd like in vX.Y.Z. Merge cutoff is <HH:MM UTC> (<local time>) Tuesday. <"Tuesday's automatic pre-release picks up everything merged by then" | "I'll cut the final pre-release after the cutoff">, and vX.Y.Z ships from it if it passes qualification. Anything that misses it goes in the next release.
    

    If the pre-release that ships was cut before the posted cutoff, say so in the thread, with its commit and time.

Tuesday: cut the release

  1. Select the final candidate. For a late cutoff, cut the final -pre.N after the cutoff as in Monday step 3. When it finishes, run the preview and repeat Monday step 2 for its run.

  2. Request approval. Present the candidate tag, commit, qualification run, compatibility assessment, commits since $PREV, and release notes preview:

    git log --oneline --no-merges "$PREV..<candidate_tag>"
    gh run download "$RUN" -n release-notes -D "$dir/notes" && cat "$dir/notes/release-notes.md"
    

    The notes come from each PR's "Release Notes" section. To fix them, edit the PR, then preview with gh workflow run release.yml --ref main -f tag="$VERSION" -f notes-only=true.

  3. Dispatch the release. After approval:

    gh workflow run release.yml --ref main -f tag="$VERSION"
    
  4. Watch and verify. Check that Select Qualified Prerelease names the approved candidate, the GitHub Release has assets, no job failed, and the wheel reached PyPI:

    gh run watch <run-id> --exit-status
    gh release view "$VERSION" --json isPrerelease,publishedAt,assets --jq '{isPrerelease, publishedAt, assets: (.assets | length)}'
    
  5. Close the loop. Draft a short reply to the coordination thread. Point to the release notes rather than repeating them:

    :white_check_mark: :ship: OpenShell vX.Y.Z is out: https://github.com/NVIDIA/OpenShell/releases/tag/vX.Y.Z
    
    It shipped from vX.Y.Z-pre.N (<commit>). I'll be starting the <next version>-pre.* jobs shortly for next week.
    
    Please check the release notes for upgrade notes that operators might care about. I'm also moving everything still open in the X.Y.Z milestone to <next milestone>.
    
    Thanks everyone!
    

    After approval, move the milestone's open items to the next milestone.

  6. Start the next train. This is this week's captain's last duty. Until the next -pre.1 exists, Auto-Tag skips. Agree with the maintainers on patch (the default) or minor (version selection). Seed it on a commit after $VERSION with a passing Release Dev run:

    for sha in $(git rev-list --max-count=10 "$VERSION..origin/main"); do
      state=$(gh run list --workflow release-dev.yml --commit "$sha" --json status,conclusion --jq '.[0] | if .status == "completed" then .conclusion else .status end')
      echo "${sha:0:9} ${state:-none} $(git log -1 --format=%s "$sha")"
    done
    

    After approval, push the tag. The -c and /dev/null keep git from signing the tag and opening an editor:

    NEXT=vX.Y.Z-pre.1 NEXT_SHA=<commit>
    git -c tag.gpgSign=false tag "$NEXT" "$NEXT_SHA" </dev/null
    git push origin "refs/tags/$NEXT"
    

    You're done when that Pre-release run passes, or its failure is handed to next week's captain.

Recovery

SymptomAction
Transient infrastructure failure in a pre-release, including a registry pushAfter approval, gh run rerun <run-id> --failed. Release won't select the run until all of it passes.
Pre-release run ends in startup_failureThe workflow file is invalid at that commit. Fix it in a new -pre.N (Monday step 3).
Code defect or Cargo Deny advisoryRerunning won't help. Fix it in a new -pre.N (Monday step 3).
Release fails after selectionAfter approval, rerun only the failed jobs that haven't published.

Related

  • release-openshell: the short procedure behind Tuesday steps 1–4.
  • watch-github-actions: general gh run monitoring and log retrieval.
  • CI.md: release workflows, qualification profile, and scanner policies.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Process one recommendation selected by ID from a local issue or CI triage report. Apply, reject, or defer it, record the outcome, and obtain separate confirmation before each change made on GitHub.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Apply one recommendation selected by its item ID
  • Reject a recommendation and record the reason
  • Defer a decision for the next queue review
NVIDIA/OpenShell1.7만2026년 10월 22일 업데이트

Turn a GitHub issue into a scoped implementation plan and, when authorized, code changes, tests, documentation, and a pull request that closes it. Check existing ownership and feedback to keep work aligned with acceptance criteria.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Creating an implementation plan from a GitHub issue
  • Implementing an authorized issue with focused tests
  • Updating documentation alongside behavior changes
NVIDIA/OpenShell1.7만2026년 10월 22일 업데이트

Maintain and validate OpenShell builds for Windows on x64 and ARM64 using MSVC, Microsoft's C++ toolchain. Check compilation, build executables, run tests on native hosts, and report artifacts and unsupported driver behavior.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Investigating Windows compilation failures
  • Building x64 and ARM64 release executables
  • Checking errors for unsupported drivers
NVIDIA/OpenShell1.7만2026년 10월 22일 업데이트

Create GitHub issues for OpenShell bugs, feature requests, and tasks using the gh command-line tool. Organize firsthand use cases, impact, and completion criteria into the project's templates, then return the created issue link.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Report an OpenShell bug you directly encountered
  • Request a feature for a specific OpenShell use case
  • Register an internal task with completion criteria
NVIDIA/OpenShell1.7만2026년 10월 22일 업데이트

Create GitHub pull requests with the gh command-line tool. Check linked issues, contributor permissions, branch conventions, and relevant tests, then prepare a title and description that follow the project's contribution rules.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Submit code changes for review
  • Open a draft pull request
  • Link a pull request to its issue
NVIDIA/OpenShell1.7만2026년 10월 22일 업데이트

Turn a design request into an OpenShell RFC, a proposal for review and discussion. The skill follows the project template, assigns an available number, and organizes motivation, alternatives, and open questions into a draft.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Drafting an architecture proposal
  • Organizing an API change proposal
  • Documenting a process change
NVIDIA/OpenShell1.7만2026년 10월 22일 업데이트

NVIDIA의 스킬 모두 보기

이 스킬의 문제 신고