feat(ci): add release pipeline and branch protection workflows

[eumaninho54]

Summary

• Add deploy.yml: pipeline triggered by DEPLOY-RELEASE comment on PRs — checks admin permission or 2 approvals, bumps package.json version, creates git tag and GitHub Release with auto-generated notes, merges PR into main
• Add enforce-release-branch.yml: rejects PRs targeting main from non-release/vX.Y.Z branches at open time
• Fix setup.sh: remove real directories before symlinking to prevent land/land nesting bug

Test plan

• Open a PR from feat/* to main — enforce-release-branch.yml should fail it with a comment
• Open a PR from release/v0.1.1 to main, comment DEPLOY-RELEASE without 2 approvals (and as non-admin) — should fail with message
• Comment DEPLOY-RELEASE as admin — should run full pipeline: version bump, tag, release, merge
• Run bash scripts/setup.sh — no land/land nesting should occur

🤖 Generated with Claude Code

[github-actions]

This PR cannot target main directly. Only release/vX.Y.Z branches may merge into main. Please retarget this PR to a release branch.

[github-actions]

This PR has been closed automatically. Only release/vX.Y.Z branches may target main. Please retarget this PR to a release branch.

[llamapreview]

Auto Pull Request Review from LlamaPReview

Recommendation: 🔴 Request Changes - This PR introduces valuable release automation with well-designed workflows, but contains critical robustness issues in the deployment pipeline (orphaned tags/releases, unsafe rm -rf usage) and important security concerns (missing PAT for CI triggers) that must be addressed before merging.

1. Overview

1.1 Core Changes

• Primary purpose: Establish automated release pipeline with branch protection
• Key components modified:
  • .github/workflows/deploy.yml: Comment-triggered release workflow (version bump, tag, release, merge)
  • .github/workflows/enforce-release-branch.yml: Branch naming enforcement for main
  • scripts/setup.sh: Fix directory nesting bug in symlink creation
• Cross-component impacts:
  • Changes release process from manual to automated
  • Enforces strict branch naming conventions
  • Affects all future merges to main
• Business value alignment:
  • Reduces manual release errors
  • Enforces consistent versioning
  • Improves developer experience

1.2 Technical Architecture

• System design modifications:
  • Introduces comment-driven workflow automation
  • Implements branch protection at PR level
  • Centralizes release operations in CI
• Component interaction changes:
  • GitHub Actions now control version bumps and merges
  • Branch naming becomes mechanically enforced
  • Release artifacts automatically generated
• Integration points impact:
  • Requires GitHub token permissions for releases
  • Affects all PRs targeting main
  • Changes how developers interact with release process
• Dependency changes:
  • Adds dependency on GitHub CLI (gh)
  • Requires jq for JSON processing

2. Critical Findings

2.1 Must Fix (P0🔴)

Issue: Orphaned release artifacts on merge failure

• Analysis Confidence: High
• Impact: Creates broken releases with tags/releases that don't match main branch state
• Resolution: Restructure workflow to create tags/releases only after successful merge

Issue: Unsafe rm -rf in setup.sh

• Analysis Confidence: High
• Impact: Potential catastrophic data loss if variables are unset/empty
• Resolution: Add explicit null/empty checks before rm -rf execution

Issue: Missing tag idempotency handling

• Analysis Confidence: High
• Impact: Pipeline fails if tag exists from previous run
• Resolution: Check for existing tags before creation

2.2 Should Fix (P1🟡)

Issue: Missing RELEASE_PAT implementation

• Analysis Confidence: High
• Impact: Breaks CI triggering and may violate branch protection rules
• Suggested Solution: Replace GITHUB_TOKEN with RELEASE_PAT for merge operations

Issue: Approval deduplication vulnerability

• Analysis Confidence: High
• Impact: Single user can bypass 2-approval requirement
• Suggested Solution: Deduplicate approvals by user login

Issue: Comment spam in branch enforcement

• Analysis Confidence: High
• Impact: Creates noise in PR conversations
• Suggested Solution: Only comment on opened/reopened events

2.3 Consider (P2🟢)

Area: Merge strategy flexibility

• Analysis Confidence: Medium
• Improvement Opportunity: Make merge strategy configurable via workflow input

Area: Dry-run capability

• Analysis Confidence: Medium
• Improvement Opportunity: Add dry-run mode for testing approval checks

Area: Release notification integration

• Analysis Confidence: Medium
• Improvement Opportunity: Add Slack/webhook notifications for release events

2.4 Summary of Action Items

1. Critical (P0): Fix tag/release ordering and add safety checks to setup.sh
2. High Priority (P1): Implement PAT, fix approval logic, and reduce comment spam
3. Future (P2): Consider merge strategy options and notification integration

3. Technical Analysis

3.1 Code Logic Analysis

📁 .github/workflows/deploy.yml - Release Pipeline

• Submitted PR Code:

    - name: Create git tag
      run: |
        git tag "${{ env.TAG }}"
        git push origin "${{ env.TAG }}"

• Analysis:
  • Current logic creates tags before merge completion
  • No check for existing tags causes idempotency issues
  • Merge failures leave orphaned tags/releases
• LlamaPReview Suggested Improvements:

    - name: Create git tag on merge commit
      run: |
        if git rev-parse "${{ env.TAG }}" >/dev/null 2>&1; then
          git tag -d "${{ env.TAG }}"
        fi
        if git ls-remote --exit-code origin refs/tags/${{ env.TAG }} >/dev/null 2>&1; then
          echo "Tag ${{ env.TAG }} already exists on remote. Failing gracefully."
          exit 1
        fi
        git tag "${{ env.TAG }}" "${{ env.MERGE_SHA }}"
        git push origin "${{ env.TAG }}"

• Improvement rationale:
  • Ensures tags only created after successful merge
  • Handles existing tags gracefully
  • Prevents orphaned release artifacts

📁 scripts/setup.sh - Symlink Creation

• Submitted PR Code:

    target="$AW_COMMANDS/$name"
    [ -d "$target" ] && [ ! -L "$target" ] && rm -rf "$target"

• Analysis:
  • Missing null checks on variables
  • Potential for catastrophic rm -rf
  • No verbose output for debugging
• LlamaPReview Suggested Improvements:

    target="$AW_COMMANDS/$name"
    if [ -n "$AW_COMMANDS" ] && [ -n "$name" ] && [ -d "$target" ] && [ ! -L "$target" ]; then
      echo "Removing existing directory $target to replace with symlink."
      rm -rf "$target"
    fi

• Improvement rationale:
  • Prevents accidental filesystem damage
  • Adds debug visibility
  • Maintains existing functionality

📁 .github/workflows/enforce-release-branch.yml - Branch Protection

• Submitted PR Code:

    on:
      pull_request:
        branches: [main]
        types: [opened, reopened, synchronize]

• Analysis:
  • Comments posted on every synchronize event
  • Creates unnecessary PR noise
  • Error checkmark sufficient for synchronize
• LlamaPReview Suggested Improvements:

    - name: Reject non-release PRs targeting main
      run: |
        if ! echo "$BRANCH" | grep -qE '^release/v[0-9]+\.[0-9]+\.[0-9]+$'; then
          if [ "${{ github.event.action }}" = "opened" ] || [ "${{ github.event.action }}" = "reopened" ]; then
            gh api repos/${{ github.repository }}/issues/${{ github.event.pull_request.number }}/comments \
              --method POST \
              --field body="This PR cannot target \`main\` directly..."
          fi
          echo "::error::..."
          exit 1
        fi

• Improvement rationale:
  • Reduces comment spam
  • Maintains protection on all events
  • Better developer experience

3.2 Key Quality Aspects

• System scalability considerations:

  • Workflow handles single PR at a time
  • No concurrency controls for simultaneous releases
  • Consider adding concurrency group for release workflow

• Performance bottlenecks and optimizations:

  • Multiple API calls could be batched
  • Consider caching PR metadata between steps
  • Parallelize independent operations where possible

• Testing strategy and coverage:

  • Test plan covers main scenarios
  • Missing tests for edge cases (conflicts, permissions)
  • Consider adding workflow_dispatch for manual testing

• Documentation needs:

  • Release process documentation required
  • Branch naming conventions need documentation
  • Approval requirements should be documented

4. Overall Evaluation

• Technical assessment:

  • Well-architected solution with proper separation of concerns
  • Critical robustness issues in deployment pipeline
  • Security concerns with token usage
  • Excellent bug fix in setup.sh

• Business impact:

  • Significant improvement in release reliability
  • Enforces consistent versioning practices
  • Reduces manual release errors
  • Potential disruption if not properly communicated

• Risk evaluation:

  • High risk of orphaned releases without fixes
  • Medium security risk from token usage
  • Low risk from branch protection changes

• Notable positive aspects and good practices:

  • Clean workflow separation
  • Good error messaging
  • Proper use of GitHub Actions features
  • Comprehensive test plan

• Implementation quality:

  • Core logic is sound
  • Missing production-grade robustness
  • Needs security hardening
  • Documentation gaps

• Final recommendation: 🔴 Request Changes

  • Critical issues must be addressed before merge
  • High priority items should be resolved
  • Future improvements can be iterative

---

Service Update
Thank you for being one of the 4,000+ repositories trusting LlamaPReview. As the AI coding landscape shifts, we are stepping back from the review SaaS model. Free reviews for private repositories will pause on May 1, 2026 00:00:00 UTC (Public open-source repos remain free).

If you've enjoyed our work, we'd be honored if you checked out our new open-source journey at DocMason.