| name | push-and-release |
| description | Automate push and release workflows for the godot-java project. (1) "推送代码" / "push code" — push code and monitor CI only. (2) "发布版本" / "release version" — full release: strip SNAPSHOT, push, CI, tag, publish to Maven Central, update downstream repos (godot-java-template, godot-java-3d-demo, godot-java-demo-projects). Only applicable in the godot-java project directory.
|
Push and Release
Two modes: push-only vs full release. Shared CI monitoring and failure handling.
Mode Selection
- User says "推送代码" or "push code" → Push mode (Step 1 → Step 2 → done)
- User says "发布版本" or "release version" → Release mode (Step 1 → Step 2 → Step 3 → Step 4 → Step 5 → done)
Prerequisites
- Working directory must be the godot-java project root
gh CLI authenticated with push access
- Clean git working tree or user-approved changes
- Release version is specified by the user (e.g., "发布版本 0.6.0"). The release workflow
overrides the version via
-Drevision from the tag name — do NOT manually edit pom.xml.
Step 1: Push
- Check
git status for uncommitted changes. If dirty, ask user whether to commit.
git push origin main
- Capture the commit SHA for CI monitoring.
Step 2: Monitor CI
- Find the CI run triggered by the push:
gh run list --workflow=ci.yml --limit 1 --json databaseId,status,conclusion
- Poll until completion (
gh run watch <id> --exit-status).
- If CI succeeds:
- Push mode → report success, done.
- Release mode → proceed to Step 3.
- If CI fails → run
gh run view <id> --log-failed, analyze errors, fix code,
commit, push, and re-monitor. Repeat until CI passes.
Step 3: Tag and Trigger Release (Release mode only)
- Use the version specified by the user (e.g., "0.6.0").
- Create and push the tag:
git tag v<version>
git push origin v<version>
- This triggers the "Release to Maven Central" workflow.
Step 4: Monitor Release (Release mode only)
- Find the release run:
gh run list --workflow=release.yml --limit 1 --json databaseId,status
gh run watch <id> --exit-status — this can take 5-10 minutes (native builds on 3 platforms).
- If release succeeds → proceed to Step 5.
- If release fails → check logs with
gh run view <id> --log-failed:
- Sonatype validation error ("Failed to associate file with coordinates"):
Try
gh run rerun <id> --failed — often a transient Sonatype issue.
- Build error: Fix the issue, delete the remote tag, re-tag and push.
- GPG/signing error: Check secrets configuration; may need manual intervention.
Repeat until release passes.
Step 5: Post-Release (Release mode only)
git pull origin main — sync the auto-bumped -SNAPSHOT version.
- Verify GitHub Release exists with native artifacts:
gh release view v<revision> --json assets --jq '.assets[].name'
- Generate and update release notes (see below).
- Update downstream repositories (see below).
- Report final status to user.
Release Notes Generation
After each release, update the GitHub Release with a proper changelog:
-
Find the previous release tag:
gh release list --limit 2 --json tagName --jq '.[1].tagName'
If no previous tag exists, use the initial commit.
-
Collect all commits since the previous release:
git log <prev-tag>..v<version> --oneline
-
Write release notes organized into sections:
- Highlights — the 3-5 most impactful changes (new features, breaking changes)
- Features — all
feat: commits, summarized concisely
- Bug Fixes — all
fix: commits, summarized concisely
- Migration from X.Y.Z — any breaking changes or important notes for users upgrading
-
Update the GitHub Release:
gh release edit v<version> --notes-file - <<'EOF'
... release notes content ...
EOF
Downstream Repositories
After a successful release, update godot-java.version in all downstream repos.
Each repo uses <godot-java.version>X.Y.Z</godot-java.version> in pom.xml.
| Repository | Local Path |
|---|
youngledo/godot-java-template | (GitHub only, use API) |
youngledo/godot-java-3d-demo | ~/Workspace/mine/godot-java-3d-demo |
youngledo/godot-java-demo-projects | ~/Workspace/mine/godot-java-demo-projects |
Local repos — sed + git push:
cd <local-path>
sed -i '' 's/<godot-java.version>[^<]*<\/godot-java.version>/<godot-java.version>VERSION<\/godot-java.version>/' pom.xml
git add pom.xml && git commit -m "Bump godot-java to VERSION" && git push origin main
GitHub-only repos — API with proper base64:
SHA=$(gh api repos/OWNER/REPO/contents/pom.xml --jq '.sha')
CONTENT=$(gh api repos/OWNER/REPO/contents/pom.xml --jq '.content' \
| base64 -d \
| sed 's/<godot-java.version>[^<]*<\/godot-java.version>/<godot-java.version>VERSION<\/godot-java.version>/' \
| base64 | tr -d '\n')
gh api repos/OWNER/REPO/contents/pom.xml -X PUT \
-f message="Bump godot-java to VERSION" -f sha="$SHA" -f content="$CONTENT"
Failure Handling Loop
For any failure (CI or release):
- Read failed logs:
gh run view <id> --log-failed
- Diagnose root cause
- Fix code or configuration
- Commit and push (for CI fixes) or re-tag (for release fixes)
- Re-monitor the triggered workflow
- Repeat until success
Do NOT give up after a single failure. Keep iterating until the full pipeline succeeds or user intervention is needed (e.g., secret rotation).