Switch release trigger from tag push to GitHub Release published event

[alongubkin]

Summary

• Replace push: tags: v* with release: types: [published] so the pipeline only fires after explicitly publishing a draft release
• Remove the github-release job — the release already exists when the workflow runs, making it redundant

Test plan

• Create a draft release on GitHub with a v* tag
• Verify the workflow does NOT trigger on draft creation
• Publish the release and verify the workflow triggers and publishes to crates.io successfully

@greptile please review

🤖 Generated with Claude Code

[linear]

ALIEN-9 Dockdash: Switch release trigger from tag push to GitHub Release published event

Currently the release workflow triggers on any v* tag push, which immediately publishes to crates.io with no opportunity to review. Switch to release: types: [published] so the flow is: create draft release → review/edit notes → publish → pipeline fires.

[alongubkin]

@greptile please review

[greptile-apps]

Greptile Summary

This PR simplifies the release workflow by switching the trigger from a raw tag push (push: tags: v*) to a GitHub Release published event (release: types: [published]), and removes the now-redundant github-release job that previously created the GitHub Release as a downstream step.

• The new trigger ensures the workflow only fires when a release is explicitly published, preventing accidental CI runs on bare tag pushes.
• Removing the softprops/action-gh-release job is correct — when the workflow is triggered by release: types: [published], the release already exists in GitHub, making re-creation redundant.
• The permissions: contents: write permission is now stale. The only remaining job (publish) calls cargo publish via a crates.io token and does not write anything back to GitHub. This should be downgraded to contents: read or removed entirely to follow the principle of least privilege.

Confidence Score: 4/5

• PR is safe to merge; the logic change is correct with one minor leftover permission to clean up.
• The trigger change and job removal are both logically sound and well-motivated. The only issue is a stale contents: write permission that is no longer needed after the github-release job was removed — this is a best-practice concern rather than a functional bug.
• .github/workflows/release.yml — verify the contents: write permission is intentionally kept or remove it.

Important Files Changed

Filename	Overview
.github/workflows/release.yml	Trigger switched from push: tags: v* to release: types: [published] and the now-redundant github-release job removed; minor issue: contents: write permission is no longer needed.

Sequence Diagram

sequenceDiagram
    participant Dev as Developer
    participant GH as GitHub
    participant WF as Release Workflow
    participant Crates as crates.io

    Note over Dev,GH: Old flow (before PR)
    Dev->>GH: git push tag v*
    GH->>WF: Trigger (push: tags v*)
    WF->>Crates: cargo publish
    WF->>GH: Create GitHub Release (softprops/action-gh-release)

    Note over Dev,GH: New flow (after PR)
    Dev->>GH: Create draft release
    Dev->>GH: Publish release
    GH->>WF: Trigger (release: types published)
    WF->>Crates: cargo publish

Loading

_{Last reviewed commit: 162ba76}

[alongubkin]

Fixed — downgraded contents: write to contents: read in d7a94b2.