Create CLI release action

[egorikftp]

• Publish CLI to maven #683
• Consider separate versioning for gradle plugin and cli #689

[coderabbitai]

Walkthrough

This PR refactors CLI release management and dependency organization. A new GitHub Actions workflow (cli-release.yml) automates CLI release operations including version extraction, release creation, and Homebrew formula updates. The main release workflow is simplified by removing CLI build and publication steps. CLI-specific dependencies (clikt, mockk, r8) are migrated from the shared Gradle version catalog to a new dedicated gradle/cli.versions.toml. Gradle configuration is updated to reference the new CLI catalog via settings.gradle.kts and tools/cli/build.gradle.kts.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20–30 minutes

• CLI version extraction and tag derivation logic in the new workflow (cli-release.yml) — verify the version parsing from TOML and tag generation logic are correct
• Homebrew formula update conditions and action parameters — ensure prerelease flag logic and snapshot handling work as intended
• Dependency migration consistency — verify all references to clikt, mockk, and r8 are correctly updated from libs.* to cli.* in tools/cli/build.gradle.kts
• Gradle version catalog registration — confirm the new catalog configuration in settings.gradle.kts is properly scoped and accessible to the CLI module

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Create CLI release action' accurately summarizes the main change: adding a new GitHub Actions workflow to automate CLI releases, which is the primary objective of this PR.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description check	✅ Passed	The PR description references related issues (#683, #689) and the PR objectives confirm this is related to creating a CLI release action, which aligns with the changeset that adds a new CLI release workflow and reorganizes dependencies.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch task/cli-action

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

.github/workflows/cli-release.yml (1)

26-48: Version extraction logic is sound but could be more defensive.

The grep+cut pattern correctly extracts the version from gradle/cli.versions.toml with the canonical TOML format shown. However, the approach is brittle: it depends on exact line formatting (no leading whitespace, specific delimiter placement). For a more robust approach, consider using a dedicated TOML parser or a more forgiving regex, but this is acceptable for internal build automation where format stability is manageable.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a0168eb and c19e9e9.

📒 Files selected for processing (6)

• .github/workflows/cli-release.yml (1 hunks)
• .github/workflows/release.yml (1 hunks)
• gradle/cli.versions.toml (1 hunks)
• gradle/libs.versions.toml (0 hunks)
• settings.gradle.kts (1 hunks)
• tools/cli/build.gradle.kts (2 hunks)

💤 Files with no reviewable changes (1)

• gradle/libs.versions.toml

🔇 Additional comments (6)

gradle/cli.versions.toml (1)

1-7: LGTM!

The new CLI version catalog is properly structured and isolates CLI dependencies (clikt, mockk, r8) with their versions pinned. This supports the refactoring to separate CLI build concerns from the main plugin release.

settings.gradle.kts (1)

43-48: LGTM!

The version catalog registration is correctly placed within dependencyResolutionManagement and will be available to the CLI module since it's included after line 48. The syntax follows Gradle best practices.

tools/cli/build.gradle.kts (2)

10-10: Version catalog access looks correct.

The cli.versions.cli.version.get() accessor properly retrieves the cli-version entry from the CLI version catalog defined in gradle/cli.versions.toml.

---

93-99: Dependency migration to CLI catalog is consistent.

All three CLI-specific dependencies (clikt, r8, mockk) are correctly switched from the shared libs.* catalog to the new cli.* catalog. The library names match entries in gradle/cli.versions.toml.

.github/workflows/release.yml (1)

58-71: LGTM!

The plugin release workflow is correctly simplified to focus on plugin artifacts only. The separation of CLI release concerns into a dedicated workflow (cli-release.yml) is a clean architectural improvement.

.github/workflows/cli-release.yml (1)

49-77: LGTM!

The complete CLI release orchestration is well-structured:

• Build task execution (line 50) integrates correctly with tools/cli/build.gradle.kts
• Release cleanup prevents orphaned tags (lines 52-59)
• Artifact path glob matches buildCLI output (line 63 matches tools/cli/build.gradle.kts line 75-76)
• Snapshot detection and pre-release flagging are consistent with main release workflow (lines 32-47, 63)
• Homebrew update is properly gated for non-snapshots with correct download URL construction (lines 65-77, line 73 aligns with archive filename generation)
• Permissions and secrets are appropriately scoped