Restrict SVN deploy to tags on main branch only

[vikasiwp]

Summary

• Adds a guard step to svn-deploy.yml that verifies the tagged commit is on main before deploying to WordPress.org
• Prevents accidental releases when a tag is created from develop or a feature branch
• Updates actions/checkout from deprecated @master to @v4

Context

Tag 0.1.2.6 was accidentally created from develop, which triggered an SVN deploy of unreleased code to WordPress.org. This guard would have caught and blocked that deploy.

Test plan

• Create a tag on a non-main branch → workflow should fail at the verify step
• Create a tag on main → workflow should pass and deploy normally

🤖 Generated with Claude Code

[claude]

Claude finished @vikasiwp's task —— View job

---

PR Review: Restrict SVN deploy to tags on main branch only

Reviewing this PR to add guards preventing accidental SVN deploys from non-main branches.

Todo List:

• Read and analyze the modified workflow file
• Review changes against security and best practices
• Assess effectiveness of the guard mechanism
• Check for potential improvements
• Provide comprehensive review feedback

✅ Overall Assessment

This PR effectively addresses the stated problem and implements a robust solution to prevent accidental deploys from non-main branches.

✅ What Works Well

Security & Safety:

• The git merge-base --is-ancestor check is the correct way to verify if a commit is reachable from a branch
• Fails fast with clear error messages using ::error:: GitHub Actions syntax
• Updates deprecated actions/checkout@master to @v4 (good maintenance)

Implementation Quality:

• Uses fetch-depth: 0 to ensure full git history is available for ancestry checks
• Clean, readable shell script with proper error handling
• Descriptive step name and informative success/error messages

✅ Effectiveness Analysis

The solution correctly addresses the root cause:

• Problem: Tag 0.1.2.6 was created from develop, triggering unwanted deploy
• Solution: Verify tag ancestry before any deploy actions occur
• Coverage: Catches tags from any non-main branch (feature branches, develop, etc.)

🔍 Minor Considerations

Edge Cases Handled:

• Works correctly for merge commits (ancestry traverses merge history)
• Handles fast-forward and non-fast-forward scenarios
• Properly references origin/main to check against remote state

Potential Future Enhancements (not blocking):

• Could add notification/Slack alert on failed verification for visibility
• Consider logging the actual branch the tag was created from for debugging

✅ Recommendation

APPROVE - This is a well-implemented safety measure that directly addresses the incident described. The solution is:

• Technically sound and robust
• Follows GitHub Actions best practices
• Provides clear feedback on failure
• Minimal and focused change

The guard will effectively prevent future accidental deploys while maintaining normal workflow for properly tagged releases.