Release Train Prep

Release Train Prep → Teams

Prepare a release train: turn a ref range into a QA checklist, post it to the train's Teams thread grouped by risk category, and (with --train) open the Final Train GitHub issue. The analysis is done entirely by scripts/release-risk-report.mjs; this skill runs it once, renders Korean HTML, and posts.

Prep, not release. This skill touches the train issue and Teams only — it never creates a release branch, pushes a tag, or publishes a GitHub release. Cutting an rc or a stable is create-release; the post-release version bump is bump-alpha-version. If the ask is "릴리즈 찍어줘" rather than "릴리즈 준비해줘", stop and use those.

Skill reference: Invoke the teams-workflow skill for Teams CLI usage.

Token economics — read this first

• Data gathering is ONE Bash call: the script emits the whole report as JSON. Never loop gh pr view over the findings — everything needed is already there.
• No repository exploration. Do not open source files, run git log, or grep the tree to "understand" a finding. The digest reports what the tool found; the reader opens the PR if they want detail.
• No TodoWrite / TaskCreate. This is linear: run → render → post.

Arguments

$ARGUMENTS may contain these in any order:

• --from <ref> — the base of the comparison. When absent, offer the choices below rather than erroring or guessing (see Resolving --from).
• --to <ref> — defaults to HEAD.
• --dry-run — preview only, no side effects anywhere: write the HTML to /tmp/release-train-prep-preview.html, skip the Teams post, and with --train also skip every tracker action (no issue, no project item) — describe what would be created instead. A dry run must never mutate anything.
• --auto — skip the confirm-before-post prompt (for cron / unattended runs).
• --train [version] — also open the release train: create the Final Train to v<version> GitHub issue and post the kickoff into the thread. The version may be omitted — it is read from the thread's own title. See Train kickoff below.
• A Teams thread URL (teams.microsoft.com/l/message/...) — required unless --dry-run. There is deliberately no default: posting a release summary to the wrong thread is not something to get wrong by omission. If the user did not give one, ask. The Teams CLI can only reply to an existing thread — it cannot open a new channel message — so the thread itself is created by a human first, which matches how the team actually runs a train.

Resolving --from

Nothing is inferred silently: no release tag is an ancestor of main in this repository (they live on the release branches, so git describe fails on main), and defaulting to the newest tag would report a whole release to someone who ran this on a feature branch. But an error is a dead end — offer the choices.

Refresh first. A stale origin/main moves the merge base and quietly changes every file-based finding, so fetch before offering it:

git fetch origin main --quiet
LATEST_TAG=$(git tag --sort=-creatordate | head -1)
# Previous tag of the SAME release line (v26.9.0-rc.3 -> the v26.9.0 line):
# an interleaved hotfix tag from another line must not become the "직전 rc".
RELEASE_LINE=${LATEST_TAG%%-*}
PREV_RC=$(git tag --sort=-creatordate | grep -F "$RELEASE_LINE" | sed -n 2p)
# Previous *stable* release, excluding LATEST_TAG itself — when the newest tag
# is already stable, this must yield the one before it, not an empty range.
PREV_STABLE=$(git tag --sort=-creatordate | grep -Ev '\-(rc|alpha|beta)\.|\+' | grep -vxF "$LATEST_TAG" | head -1)
BRANCH=$(git branch --show-current)

Then ask with AskUserQuestion, putting the option that matches the current HEAD first and marking it (Recommended). On a feature branch that is the branch diff; on a release branch or a detached tag it is the release comparison.

Offer the last row only when $LATEST_TAG is a prerelease. The two release rows are far apart in size and answer different questions — at the time of writing, $PREV_STABLE..$LATEST_TAG was 175 commits and $PREV_RC..$LATEST_TAG was 18 — so do not collapse them into one "previous tag" option.

AskUserQuestion always offers Other, which is how the user supplies a ref this list does not cover (an older tag, another branch, a SHA) — take that string verbatim as --from. Do not pre-validate it; the script fails loudly on a bad ref.

Say which ref you resolved to in the reply, so a wrong pick is visible before the message reaches Teams.

Process

1. Run the report — ONE Bash call

Must run from a backend.ai-webui checkout; the script shells out to git in the current directory. By this point $FROM is whatever Resolving --from settled on — the script itself takes no default and exits 2 without one.

TO="${TO:-HEAD}"   # --to is optional; an empty string would override the script's default
node scripts/release-risk-report.mjs --from "$FROM" --to "$TO" --json > /tmp/release-risk.json

If the script exits non-zero, report the message and stop. Do not fall back to reading git history by hand.

2. Read the JSON

Top-level fields:

3. Render the HTML

The digest answers one question for the reader: 릴리즈 준비 때 어떤 기능을 집중적으로 만져봐야 하는가. Sections in order:

1. ✨ 주요 변경 — the user-facing story: new features, then the existing features that changed the most
2. R2 version-gating gaps — a query that fails outright on older managers
3. R2b undeclared flags — a feature silently off everywhere (omit when empty)
4. R3 untranslated — ships visibly broken text
5. R1 UI without e2e — the manual-pass list
6. R5 manual gaps

R4 (destructive-flow touches) stays in the full --out report for reviewers, but the digest does not carry it — the team asked for feature-level focus, not file-level caution.

Keep it short. A Teams message is read on a phone. Per section list at most 5 items and append 외 N건 when there are more. For R3, do not list 40 locale files — collapse to the shape (대부분의 언어에서 placeholder N개 / 누락 M개) and name only the outliers.

외 N건 is a size fold, nothing else. It means "N more of the same kind that did not fit", so the reader can ask for them and get a list of equals. An item you drop for a reason — not manual material, not user-facing, a false positive — is never folded into it: either leave it out entirely (the script already does this for R5) or name it with its reason. The rc.4 thread had to ask what "외 4건" were because a triage was hiding inside a fold.

HTML safety: escape &, <, >, ", ' in every string taken from the JSON (PR subjects, file paths, flag names) before inserting it. Emit only <b>, <i>, <br/>, <ul>, <li>, <a href="...">, <code>, <hr/>. Escape & in URLs too.

PR links are https://github.com/lablup/backend.ai-webui/pull/{pr}.

Template:

Name releases, not refs. The header speaks in release versions: for an upcoming stable cut from main, 26.8.1 → 26.9.0(예정, 현재 main 기준) — never a bare v26.8.1 → origin/main, which readers cannot place on the release line.

Template:

<b>🚀 릴리즈 준비 — {이전 정식} → {다음 버전}(예정, 현재 {to} 기준)</b><br/>
커밋 {commits.length}건{, 비교 기준 merge-base <code>{base[0:8]}</code> when divergedFrom}<br/><br/>

<b>✨ 새 기능</b> — {feat 커밋 수}건<br/>
<ul>
  <li><a href="{prUrl}">#{pr}</a> {사용자 관점 한 줄 설명}</li>
</ul>
{외 N건}<br/>

<b>🔧 많이 바뀐 기존 기능</b><br/>
<ul>
  <li><b>{영역 한글명}</b> — 변경 {commits}건 (<a>#{pr}</a>, <a>#{pr}</a>, …)</li>
</ul>
<i>릴리즈 테스트에서 이 기능들을 우선적으로 확인해 주세요.</i><br/><br/>

<b>⚙️ 버전 게이팅 누락</b> — {gating.gaps.length}건<br/>
<ul>
  <li><code>{key}</code> ({version} 추가) — <code>{ungated file}</code>에서 @since 없이 사용</li>
</ul>
<i>낮은 버전 매니저에서 이 쿼리는 실패합니다. @since(version:) 주석 또는 supports() 게이트가 필요합니다.</i><br/><br/>

<b>🌐 미번역</b> — 신규 영어 키 {addedCount}개<br/>
{shape line, then outliers}<br/><br/>

<b>🧪 e2e 미커버 UI 변경</b> — {n}건<br/>
<ul><li><a href="{prUrl}">#{pr}</a> {subject}</li></ul>
{외 N건}<br/><br/>

<b>📖 매뉴얼 미반영</b> — {n}건<br/>
<ul><li><a href="{prUrl}">#{pr}</a> {subject}</li></ul>
{외 N건}
<hr/>
<i>🤖 scripts/release-risk-report.mjs · 결함 목록이 아니라 QA 확인 항목입니다</i>

How each special section is written:

• 새 기능: every feat commit, but the line is YOURS to write — a Korean sentence describing what the user can now do, synthesized from the subject ("pick the model mount subpath with a directory picker" → "모델 마운트 경로를 디렉터리 탐색기로 선택"). Never paste raw commit subjects here. Cap at ~6 lines + 외 N건.
• 많이 바뀐 기존 기능: hotspots[] top ~5. Translate the area token into the UI's own term (VFolder → 폴더, Deployment → 배포/디플로이먼트 — the i18n label wins, per the terminology precedence), show the change count and 2–3 PR links. This is the "여기를 우선 테스트" list.
• 버전 게이팅 (R2): gaps ONLY — never enumerate every new gate or schema field; a correctly annotated usage is not news. When gating.gaps is empty, keep the section as the single line ⚙️ 버전 게이팅 누락 — 없음 ✅: for a go/no-go reader, "checked and clean" and "not checked" must not look the same.
• 매뉴얼 미반영 (R5): risks.noDocs[] is the list and the heading count is its length. Feats the script set aside (risks.noDocsSkipped[]: dev tooling, library-only, no page surface) are not counted and not mentioned — they are already in 새 기능 and the commit list. If one of them does deserve a manual entry, fix isManualFacing in the script rather than editing the digest.

Drop any other section whose count is 0 rather than printing an empty heading. If every section is empty, post a single line saying the range has no risk signals.

The closing italic line matters: these are actions to check, not confirmed defects. Do not phrase a finding as a bug.