feat: add Homebrew tap support

[AlmogBaku]

Summary

• Add homebrew job to release workflow that auto-updates AlmogBaku/homebrew-tap formula on each release
• Compute SHA256 for all 4 platform binaries (darwin/linux × amd64/arm64) with proper error handling (set -euo pipefail)
• Add Homebrew install option to README and SKILL.md

Setup required

1. Create a fine-grained PAT scoped to AlmogBaku/homebrew-tap with Contents: write permission
2. Add it as secret HOMEBREW_TAP_TOKEN in this repo's settings

Install

brew install AlmogBaku/tap/dap

Test plan

• brew install AlmogBaku/tap/dap works locally with current formula
• dap --version shows correct version after install
• Verify HOMEBREW_TAP_TOKEN secret is configured
• Verify next release triggers the homebrew job and updates the formula

🤖 Generated with Claude Code

[qodo-free-for-open-source-projects]

Review Summary by Qodo

Add Homebrew tap support for dap CLI

✨ Enhancement

Walkthroughs

Description

• Add Homebrew tap support with auto-updating formula on releases
• Compute SHA256 checksums for all platform binaries (darwin/linux × amd64/arm64)
• Update README and SKILL.md with Homebrew installation instructions
• Implement robust error handling with set -euo pipefail in release workflow

Diagram

flowchart LR
  Release["Release Workflow"] -- "triggers" --> Homebrew["Homebrew Job"]
  Homebrew -- "downloads binaries" --> GitHub["GitHub Releases"]
  Homebrew -- "computes SHA256" --> Checksums["Platform Checksums"]
  Checksums -- "updates formula" --> TapRepo["homebrew-tap Repo"]
  TapRepo -- "enables install" --> User["brew install AlmogBaku/tap/dap"]

Loading

File Changes

1. .github/workflows/release.yml ✨ Enhancement +80/-0

Add Homebrew formula auto-update job to release workflow

• Add new homebrew job that triggers after release completion
• Download all 4 platform binaries and compute SHA256 checksums with error handling
• Generate Homebrew formula file with platform-specific URLs and checksums
• Commit and push updated formula to AlmogBaku/homebrew-tap repository

.github/workflows/release.yml

---

2. README.md 📝 Documentation +7/-0

Add Homebrew install instructions to README

• Add Homebrew installation method as primary option in install section
• Reorganize installation methods with collapsible details section
• Maintain existing one-liner and source installation options

README.md

---

3. skills/debugging-code/SKILL.md 📝 Documentation +10/-1

Add Homebrew install option to SKILL documentation

• Add Homebrew installation option for macOS users
• Restructure installation instructions with clear method labels
• Improve formatting and readability of install alternatives

skills/debugging-code/SKILL.md

---

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Unguarded tap token usage ☑ 🐞 Bug ⛯ Reliability

Description

The new homebrew job always uses secrets.HOMEBREW_TAP_TOKEN to checkout/push, so if the secret
is missing/misconfigured the overall release workflow will fail even though the GitHub Release was
already created. This creates a partial-release state (release published, tap not updated) and marks
the workflow as failed.

Code

.github/workflows/release.yml[R102-105]

+      - uses: actions/checkout@v4
+        with:
+          repository: AlmogBaku/homebrew-tap
+          token: ${{ secrets.HOMEBREW_TAP_TOKEN }}

Evidence

The workflow creates the GitHub release in the release job, then the homebrew job runs
afterwards and unconditionally attempts to authenticate with HOMEBREW_TAP_TOKEN; missing
credentials will fail the job and thus the workflow run.

.github/workflows/release.yml[78-106]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `homebrew` job unconditionally uses `secrets.HOMEBREW_TAP_TOKEN`. When the secret is missing/misconfigured, the workflow fails even though the GitHub release was already created.
### Issue Context
This job runs after `release` and pushes to an external tap repo. Missing credentials should either skip this job or fail without failing the whole workflow.
### Fix Focus Areas
- .github/workflows/release.yml[96-106]
### Suggested change
- Add a guard such as:
- `if: ${{ needs.version.outputs.tag != '' && secrets.HOMEBREW_TAP_TOKEN != '' }}`
- Optionally add an explicit step that prints a clear message when skipping.
- Alternatively, set `continue-on-error: true` for the job/steps if a missing token should not fail the release pipeline.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Tag/URL consistency not enforced ☑ 🐞 Bug ✓ Correctness

Description

The workflow computes SHA256 values from URLs built with ${VERSION} while the generated formula
hardcodes a v prefix via v#{version}, so if the tag ever lacks a leading v (or the tag format
changes), the resulting formula URLs and checksums won’t correspond and brew install will fail.
The workflow currently relies on an implicit tag-format invariant but does not validate/enforce it
in code.

Code

.github/workflows/release.yml[R112-134]

+          VER="${VERSION#v}"
+          BASE="https://github.com/AlmogBaku/debug-skill/releases/download/${VERSION}"
+
+          sha() { curl -sfL "$1" | shasum -a 256 | cut -d' ' -f1; }
+          SHA_DARWIN_ARM64=$(sha "${BASE}/dap-darwin-arm64") || { echo "Failed to download darwin-arm64"; exit 1; }
+          SHA_DARWIN_AMD64=$(sha "${BASE}/dap-darwin-amd64") || { echo "Failed to download darwin-amd64"; exit 1; }
+          SHA_LINUX_ARM64=$(sha "${BASE}/dap-linux-arm64") || { echo "Failed to download linux-arm64"; exit 1; }
+          SHA_LINUX_AMD64=$(sha "${BASE}/dap-linux-amd64") || { echo "Failed to download linux-amd64"; exit 1; }
+
+          cat > Formula/dap.rb << 'FORMULA'
+          class Dap < Formula
+            desc "CLI debugging tool for AI agents using the Debug Adapter Protocol"
+            homepage "https://github.com/AlmogBaku/debug-skill"
+            version "VERSION_PLACEHOLDER"
+            license "MIT"
+
+            on_macos do
+              if Hardware::CPU.arm?
+                url "https://github.com/AlmogBaku/debug-skill/releases/download/v#{version}/dap-darwin-arm64"
+                sha256 "SHA_DARWIN_ARM64_PLACEHOLDER"
+              else
+                url "https://github.com/AlmogBaku/debug-skill/releases/download/v#{version}/dap-darwin-amd64"
+                sha256 "SHA_DARWIN_AMD64_PLACEHOLDER"

Evidence

The SHA source URLs are derived from ${VERSION} directly, but formula URLs are derived from
version with an unconditional v prefix; these are only consistent if ${VERSION} is always
exactly v${VER}. That invariant is assumed but not checked anywhere in the script.

.github/workflows/release.yml[111-145]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
SHA256 values are computed from `${BASE}` where `BASE` uses `${VERSION}` directly, but the formula URLs use `v#{version}` where `version` is derived from `${VERSION#v}`. If `${VERSION}` is ever not `v<semver>`, the formula will reference different URLs than were hashed.
### Issue Context
This is currently an implicit assumption about tag format. The workflow should either enforce the tag format or generate URLs based on the tag string actually used.
### Fix Focus Areas
- .github/workflows/release.yml[112-145]
### Suggested change
- Derive a single tag variable and use it consistently, e.g.:
- `VER="${VERSION#v}"`
- `TAG="v${VER}"`
- Use `TAG` for both SHA downloads and formula URLs.
- Add a validation guard:
- `[[ "${VERSION}" == v* ]] || { echo "Expected v-prefixed tag, got ${VERSION}"; exit 1; }`
(or adjust to support non-v tags by removing the hardcoded `v` prefix in the formula URLs).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. ARM CPU check too broad 🐞 Bug ✓ Correctness

Description

The generated formula uses Hardware::CPU.arm? to select the *-arm64 binaries, but the release
workflow only builds arm64 (no other ARM variants). This will mis-handle non-arm64 ARM environments
by fetching an incompatible/missing arm64 binary.

Code

.github/workflows/release.yml[R128-145]

+            on_macos do
+              if Hardware::CPU.arm?
+                url "https://github.com/AlmogBaku/debug-skill/releases/download/v#{version}/dap-darwin-arm64"
+                sha256 "SHA_DARWIN_ARM64_PLACEHOLDER"
+              else
+                url "https://github.com/AlmogBaku/debug-skill/releases/download/v#{version}/dap-darwin-amd64"
+                sha256 "SHA_DARWIN_AMD64_PLACEHOLDER"
+              end
+            end
+
+            on_linux do
+              if Hardware::CPU.arm?
+                url "https://github.com/AlmogBaku/debug-skill/releases/download/v#{version}/dap-linux-arm64"
+                sha256 "SHA_LINUX_ARM64_PLACEHOLDER"
+              else
+                url "https://github.com/AlmogBaku/debug-skill/releases/download/v#{version}/dap-linux-amd64"
+                sha256 "SHA_LINUX_AMD64_PLACEHOLDER"
+              end

Evidence

The release pipeline publishes only arm64 artifacts for Linux/macOS, but the formula treats any ARM
as arm64, so the formula’s architecture selection is broader than the artifacts produced.

.github/workflows/release.yml[41-55]
.github/workflows/release.yml[128-145]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The formula uses `Hardware::CPU.arm?` which matches ARM broadly, but the project only releases arm64 binaries. This can lead to the formula selecting `*-arm64` assets on unsupported ARM variants.
### Issue Context
The release workflow build matrix only produces `arm64` artifacts; the formula should mirror that specificity.
### Fix Focus Areas
- .github/workflows/release.yml[121-146]
- .github/workflows/release.yml[43-55]
### Suggested change
- Replace `Hardware::CPU.arm?` with an arm64-specific predicate in both macOS and Linux sections.
- Optionally add an explicit `odie`/error message for unsupported architectures (so failures are clear instead of checksum/exec-format errors).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more