[#10478] feat(release): add gravitino-release skill and fix state-dir path bug#10479
[#10478] feat(release): add gravitino-release skill and fix state-dir path bug#10479jerryshao wants to merge 4 commits intoapache:mainfrom
Conversation
There was a problem hiding this comment.
Is the content of this file identical to that of dev/release/gravitino-release/SKILL.md? Can we use a symbolic link?
There was a problem hiding this comment.
The one in the .claude is used for my test. My plan is to only maintain the skill in dev/release, users can manually install them in anywhere. WDYT?
|
Overall, the workflow looks generally fine. One area for improvement would be to split this skill into multiple smaller skills to reduce context contamination. You could use one skill to orchestrate the overall process, for example release-workflow, and then split the concrete execution steps into separate functional skills, such as: The release-workflow skill could then invoke these functional skills and handle them through sub-agents. |
My feeling is that using subagent is not so useful. Because the step has a sequence, it cannot be executed in parallel. And since I controlled the workflow, so currently there's no chance to skip the stages. The one concern is that this skill file is too big, but I've met any context window issue for now. Yes, there's some advanced tricks to improve the skill file, I need to investigate more. |
Code Coverage Report
|
…te-dir path bug
- Add dev/release/gravitino-release/SKILL.md: a Claude Code skill that
guides the release manager through all 7 stages (tag, build, docs,
publish, docker, finalize, release-note) with state tracking, mock
mode, dry-run support, preflight checks, and credential collection.
- Add dev/release/mock/do-release.sh and mock/publish-docker.sh: mock
scripts that simulate all stages without real operations, used for
testing the skill end-to-end.
- Fix do-release.sh and mock/do-release.sh: STATE_DIR defaulted to a
relative path (.release-state), causing state files to be written to
the caller's working directory. Fixed to use $SELF/.release-state.
- Fix mock/do-release.sh: log files also used a relative path; fixed
to use $SELF/${STEP}.log.
- Fix publish-docker.sh: same relative STATE_DIR bug; add SELF and
anchor DOCKER_STATE_DIR to $SELF/.release-state.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…kills and add README - Move gravitino-release/ from dev/release/ to agent-skills/ - Update installation paths in SKILL.md to reflect new location - Add README.md with usage instructions, prerequisites, and mock mode guide Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
@mchades please help to review. |
3 participants
What changes were proposed in this pull request?
dev/release/gravitino-release/SKILL.md: a Claude Code skill that acts as an interactive release manager, guiding through all 7 stages (tag, build, docs, publish, docker, finalize, release-note) with state tracking, mock mode, dry-run support, preflight checks, and credential collection.dev/release/mock/do-release.shanddev/release/mock/publish-docker.sh: mock scripts that simulate all stages without real operations, for safe end-to-end testing of the skill.STATE_DIRpath bug indo-release.sh,mock/do-release.sh, andpublish-docker.sh: the default.release-statewas a relative path, causing state files to be written to the caller's working directory instead of alongside the scripts. Fixed to use$SELF/.release-state.mock/do-release.sh: log files also used a relative path; fixed to use$SELF/${STEP}.log.Why are the changes needed?
Fix: #10478
The release process is complex and multi-staged. Without structured tooling, a release manager must remember which stages have run, which credentials are needed, and how to recover from failures. The skill automates this orchestration. The state-dir bug caused state files to be scattered in unpredictable locations depending on where scripts were invoked from, breaking resume-after-failure behavior.
Does this PR introduce any user-facing change?
No API or property key changes. The skill and mock scripts are new developer tooling only.
How was this patch tested?
Tested end-to-end using mock mode (
dev/release/mock/do-release.sh) with all 7 stages, including failure simulation viaMOCK_FAIL_STAGE, dry-run mode, and resume-from-partial-state scenarios.