hanzoai/dev
2
0
Fork 0
mirror of https://github.com/hanzoai/dev.git synced 2026-10-25 03:32:32 +00:00
Code Issues Packages Projects Releases Wiki Activity

ci(release): fix YAML by indenting heredoc content in run block

Browse Source
This commit is contained in:
James Peter
2025-09-05 17:26:02 +10:00
parent f673599221
commit 7373a34fe4
1 changed files with 38 additions and 38 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/workflows/release.yml
+38 -38
View File
@@ -479,50 +479,50 @@ jobs:
# Build the task prompt (with variables expanded by bash).
cat > release-notes/prompt.expanded.txt <<PROMPT
You are Code running headless in CI to prepare a new release.
You are Code running headless in CI to prepare a new release.
Inputs
- Version: v${NEW_VERSION}
- Date (UTC): ${DATE}
- Previous tag: ${PREV_TAG:-none}
- Commit range: ${RANGE}
- Working directory: repo root (CHANGELOG.md lives at top-level)
Inputs
- Version: v${NEW_VERSION}
- Date (UTC): ${DATE}
- Previous tag: ${PREV_TAG:-none}
- Commit range: ${RANGE}
- Working directory: repo root (CHANGELOG.md lives at top-level)
Primary Tasks
1) Update CHANGELOG.md with a new entry for this version using the EXACT house style below.
2) Generate GitHub release notes at release-notes/RELEASE_NOTES.md (concise, user‑facing), derived from the same changes.
Primary Tasks
1) Update CHANGELOG.md with a new entry for this version using the EXACT house style below.
2) Generate GitHub release notes at release-notes/RELEASE_NOTES.md (concise, user‑facing), derived from the same changes.
CHANGELOG.md House Style (strict)
- File header stays as-is ("Changelog"). Do not rewrite older sections.
- Insert the new section at the top (above previous versions), with this header format exactly:
## [${NEW_VERSION}] - ${DATE}
- Include 2–5 bullets, each a single line, focusing on user‑visible features, fixes, UX, performance, or stability.
- Keep bullets concise and scannable; avoid long prose. Prefer present tense.
- When helpful, start bullets with a short scope label like "TUI:", "CLI:", or "Core:".
- At the end of each bullet, include abbreviated commit SHA(s) in parentheses, using 7–8 hex chars, comma‑separated when multiple, like: (abc1234, def5678).
- Map changes from the git commit log in ${RANGE}; ignore pure chores/merges unless user‑visible.
- Do NOT add links, tables, or subheadings. Do NOT include PR author attributions in the changelog.
- Idempotent: if a section for ${NEW_VERSION} already exists, replace only that section’s body with the newly generated bullets and keep the header intact.
CHANGELOG.md House Style (strict)
- File header stays as-is ("Changelog"). Do not rewrite older sections.
- Insert the new section at the top (above previous versions), with this header format exactly:
## [${NEW_VERSION}] - ${DATE}
- Include 2–5 bullets, each a single line, focusing on user‑visible features, fixes, UX, performance, or stability.
- Keep bullets concise and scannable; avoid long prose. Prefer present tense.
- When helpful, start bullets with a short scope label like "TUI:", "CLI:", or "Core:".
- At the end of each bullet, include abbreviated commit SHA(s) in parentheses, using 7–8 hex chars, comma‑separated when multiple, like: (abc1234, def5678).
- Map changes from the git commit log in ${RANGE}; ignore pure chores/merges unless user‑visible.
- Do NOT add links, tables, or subheadings. Do NOT include PR author attributions in the changelog.
- Idempotent: if a section for ${NEW_VERSION} already exists, replace only that section’s body with the newly generated bullets and keep the header intact.
Release Notes (release-notes/RELEASE_NOTES.md)
- Title: ## @just-every/code v${NEW_VERSION}
- Brief intro (1-2 sentences) on core focus of release. This is the one place you can use a more promotional & humorous tone e.g. "**HUGE** performance upgrades! You won't have time for that coffee any more with significantly reduced startup time."
- A Changes section with the same 2–5 bullets as in CHANGELOG (you may omit the commit SHAs here).
- Installation snippet:
npm install -g @just-every/code
code
- Optional last line: "Compare: ${PREV_TAG:-<none>}...v${NEW_VERSION}" if a previous tag exists.
- Keep notes concise; no walls of text.
Release Notes (release-notes/RELEASE_NOTES.md)
- Title: ## @just-every/code v${NEW_VERSION}
- Brief intro (1-2 sentences) on core focus of release. This is the one place you can use a more promotional & humorous tone e.g. "**HUGE** performance upgrades! You won't have time for that coffee any more with significantly reduced startup time."
- A Changes section with the same 2–5 bullets as in CHANGELOG (you may omit the commit SHAs here).
- Installation snippet:
npm install -g @just-every/code
code
- Optional last line: "Compare: ${PREV_TAG:-<none>}...v${NEW_VERSION}" if a previous tag exists.
- Keep notes concise; no walls of text.
Rules
- Use the provided git log as source of truth; summarize responsibly.
- Explore codebase directly if commit messages are unclear or need additional context.
- Keep formatting minimal (headers + list bullets). No emojis ever! Basic markdown only.
- Never reorder older versions. Only touch the section for v${NEW_VERSION}.
- After writing files, stage and commit with message: docs(changelog): update for v${NEW_VERSION}
Rules
- Use the provided git log as source of truth; summarize responsibly.
- Explore codebase directly if commit messages are unclear or need additional context.
- Keep formatting minimal (headers + list bullets). No emojis ever! Basic markdown only.
- Never reorder older versions. Only touch the section for v${NEW_VERSION}.
- After writing files, stage and commit with message: docs(changelog): update for v${NEW_VERSION}
Context (git log excerpt follows):
PROMPT
Context (git log excerpt follows):
PROMPT
cat release-notes/context.md >> release-notes/prompt.expanded.txt
# Run Code in fully automated exec mode against the repo root.