gh workflow run failed inside successCmd (exit 1, no output shown).
Switch to gh api REST dispatch which is transparent and reliable.
successCmd only runs after semantic-release actually publishes a new
version, so this fires once per release, exactly on the new tag.
Remove the separate Detect step (it depended on git state that is not
updated by semantic-release).
The prior pattern relying on steps.semantic-release.outputs did not
fire. Move the publish dispatch into @semantic-release/exec successCmd,
which runs only after a release is actually published and has
nextRelease.version available. Also add GH_TOKEN env for gh CLI
(GITHUB_TOKEN alone is not read by gh).
cargo check --locked fails after bumping version in Cargo.toml because
Cargo.lock needs to be regenerated with the new root package version.
Semantic-release bump then committed Cargo.toml+CHANGELOG but lockfile
stayed stale, so the whole prepare step errored out.
- Add .releaserc.json: conventional commits -> semantic version bump
(major/minor/patch), updates Cargo.toml + Cargo.lock version, writes
CHANGELOG.md, commits as 'chore(release): X.Y.Z [skip ci]'
- Add release.yml: runs semantic-release on main push, then triggers
publish.yml via workflow_dispatch with the new tag
- Update publish.yml: add workflow_dispatch input (tag) so release
workflow can trigger publish directly (GITHUB_TOKEN tag pushes do not
trigger 'on: push: tags'); still supports manual tag pushes
2026-08-28 17:03:12 +07:00
6 changed files with 135 additions and 2 deletions
* **release:** dispatch publish via gh api in exec successCmd ([3c04aa4](https://github.com/asepharyana/corex/commit/3c04aa44b6110c8ce15278d7dc76828c44dfc8d9))
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
semantic-release-bot
asepharyana