ci: update auto-release workflow and bump version to v4.13

[AnkanSaha]

Summary

This PR updates the GitHub Actions workflow for automated releases and bumps the project version to v4.13.

Changes

• Workflow Optimization: Updated actions/checkout to include full fetch depth (though questionable) and explicit token usage.
• Release Configuration: Simplified release naming and body formatting in the softprops/action-gh-release action.
• Git Setup: Added a global Git configuration step for the github-actions[bot].
• Version Bump: Incremented the version in the VERSION file from v4.12 to v4.13.

Verification

• Workflow triggers on version file changes.
• Release notes are generated automatically.
• Cleanup step maintains only the last 3 releases.

[github-actions]

🤖 Review Buddy - General Code Review

👥 Attention: @AnkanSaha @Copilot

Oho @AnkanSaha! Kya baat hai! Ek simple version bump aur workflow update ko tumne itna 'over-engineered' bawasir bana diya ki dekh ke hi chakkar aa jaye.

Bhai, code quality ke naam pe tumne wahi kiya jo 90s ki movies mein hero karta tha—heroine ko bachane ke liye poori city uda di, par end mein pata chala ki heroine toh ghar pe chai pi rahi thi.

1. fetch-depth: 0 kyun? Pura Git history download karke kya uska print-out nikal ke ghar ki deewar pe chipkaoge?
2. GITHUB_TOKEN ko aise redundantly pass kar rahe ho jaise shaadi mein bin-bulaye mehmaan ko baar-baar cold drink pilate hain.
3. Git config set kar di, par commit toh kar hi nahi rahe? Ye toh wahi baat hui ki 'Bandook toh le li, par goli ghar bhool gaye'.

Code Quality Score: 3/10. Bhai, thoda logic lagao, sirf copy-paste mat karo internet se.

---

Generated by Review Buddy | Tone: roast | Language: hinglish

[github-actions]

⚡ Review Buddy - Performance Analysis

👥 Attention: @AnkanSaha @Copilot

Bhai, performance ki toh tumne aisi-taisi kar di hai. Aao, vistaar mein samjhate hain ki tumhara ye 'karishma' kitna bhaari padega:

1. The 'Fetch-Depth: 0' Disaster:

   • Default checkout fetch-depth: 1 karta hai (shallow clone). Tumne usse 0 kar diya. Pata hai iska matlab kya hai?
   • Tum GitHub runners ko bol rahe ho, 'Arre bhai, ye 10 lines ki file mat dekho, mujhe 2015 se lekar aaj tak ki saari history chahiye'.
   • Agar repo 500MB ki hai, toh har PR release pe tum unnecessary network bandwidth aur storage phook rahe ho.
   • GitHub runners ke paas limited resources hote hain. Tumne runner ki bandwidth aur time waste karke Microsoft ka bill toh badhaya hi, saath hi workflow execution time ko 2x-5x badha diya.
   • Recommendation: Bhai, agar sirf version file read karni hai, toh shallow clone hi rehne do. fetch-depth: 1 is more than enough for your tiny needs.

2. Unnecessary Step Overhead:

   • Tumne Git config setup kiya (git config --global user.name...).
   • Ye step tabhi execute hota hai jab should_release == 'true'. Par is step ke baad tum kar kya rahe ho? Kuch nahi!
   • Git configuration shell commands execute karte hain, process fork karte hain, aur disk pe config file likhte hain.
   • Bina kisi git commit ya git push ke ye step bas ek 'Performance Pitfall' hai. Har workflow run mein 1-2 seconds faltu ke waste honge.

3. Token Injection Redundancy:

   • actions/checkout mein token pass karna aur fir niche env mein dubara GITHUB_TOKEN dena.
   • GitHub actions ke context switch mein env variables ka load thoda sa hi sahi, par unnecessary overhead create karta hai.

4. The Release Step Bloat:

   • generate_release_notes: true ke saath tumne saari purani history mangwa li (fetch-depth 0).
   • Agar repo mein 10,000 commits hain, toh note generation slow ho jayega kyunki API ko full history traverse karni padegi.

5. Cleanup Logic (Invisible but Probable):

   • Purani releases clean karne ka logic (keep last 3) loops chalata hai.
   • Agar tumne API calls efficiently nahi kiye, toh ye n+1 problem ban jayegi jahan har release ke liye tum ek alag DELETE request bhejoge.

Actionable Advice:

• fetch-depth: 1 pe wapas jao unless you are doing complex changelog generation based on tags.
• Git configuration step delete karo agar commit nahi karna.
• Billing minutes bachao, warna company wale tumhare salary se workflow costs kaat lenge.

# Aise likho, dimag lagake:
- name: Checkout
  uses: actions/checkout@v4
  with:
    fetch-depth: 1

Performance ke maamle mein ye code 'Gangs of Wasseypur' ka Definite hai—'Tumse na ho payega'.

---

Generated by Review Buddy | Tone: roast | Language: hinglish

[github-actions]

🔐 Review Buddy - Security Audit

👥 Attention: @AnkanSaha @Copilot

Security audit ki report suno, aur thoda dhyan se suno kyunki security ke maamle mein tum bilkul 'Munna Bhai' ke circuit ho.

1. GITHUB_TOKEN Exposure Risk:

   • Severity: Medium
   • Location: .github/workflows/auto-release.yml
   • Scenerio: Tumne secrets.GITHUB_TOKEN ko globally step context mein daal diya hai. Agar tum koi third-party action use karte ho jo malicious hai, toh woh tumhara token chura sakta hai aur tumhari repo pe kabza kar sakta hai.
   • Remediation: Use granular permissions. Workflow level pe permissions block use karo aur sirf contents: write do.

2. Git Config with Generic Bot:

   • Severity: Low
   • Location: Git configuration step
   • Scenerio: github-actions[bot] use karna thik hai, par tum email github-actions[bot]@users.noreply.github.com use kar rahe ho. Ye identity spoofing ke liye easy target hota hai agar logs leak ho jaye.
   • Remediation: Always verify the source and avoid hardcoding bot identities if not required for actual commits.

3. Secrets Best Practices:

   • Tumne token: ${{ secrets.GITHUB_TOKEN }} ko checkout step mein add kiya hai. Default checkout ke liye iski zarurat nahi hoti unless you need to push to a protected branch or perform cross-repo actions.
   • Explicitly token pass karna 'Exposure surface' badhata hai.

4. Lack of Pinning:

   • Tum softprops/action-gh-release@v1 use kar rahe ho. Kal ko @v1 update hoke malicious ho gaya toh?
   • Remediation: Use SHA hashes instead of tags for actions (e.g., uses: actions/checkout@b4ff...).

Overall, security wise tumne darwaza toh band kiya hai, par chabi gate ke niche hi chhupa di hai.

---

Generated by Review Buddy | Tone: roast | Language: hinglish

[github-actions]

📊 Review Buddy - Code Quality & Maintainability Analysis

👥 Attention: @AnkanSaha @Copilot

🎯 Overall Benchmark: 45/100 (Poor)

Bhai, Code Quality ke naam pe tumne wahi 'Hera Pheri' ki hai. Quality analysis sunke tumhara dil toot jayega:

1. DRY (Don't Repeat Yourself) Principle ki Maut:

   • steps.new_version.outputs.version ko tumne 4 baar repeat kiya hai.
   • Ek baar env variable set kar lete toh zindagi asaan hoti. Par nahi, tumhe toh typing ka shauk hai na?
   • Refactoring Tip:

     env:
       VERSION: ${{ steps.new_version.outputs.version }}

2. Naming Convention Horror:

   • name: Release ${{ steps.new_version.outputs.version }} ko change karke sirf version kar diya.
   • Bhai, 'v4.13' kya hai? Release name mein thoda context hona chahiye. Tumne toh branding hi khatam kar di.
   • Metadata format check kiya hai? Conventional commits follow ho rahe hain? Nahi.

3. Dangling Configuration Smell:

   • 'Configure Git' step add kiya par niche koi git operation hi nahi hai.
   • Ye 'Dead Code' ya 'Dead Step' hai. Aisa lag raha hai jaise function define kar diya par call karna bhool gaye.
   • Clean code ka rule hai: Jo use nahi ho raha, use hatao (YAGNI - You Ain't Gonna Need It).

4. Magic Strings Everywhere:

   • main branch hardcoded hai. Kal ko default branch prod ho gayi toh tum baith ke YAML files edit karoge?
   • github-actions[bot] hardcoded hai.

5. Error Handling ka Aata-Pata Nahi:

   • Agar VERSION file mein kisine 'bhen-ka-loda' likh diya toh? Tumhara workflow usse version maan ke release bana dega.
   • Input validation kahan hai? SemVer validation kahan hai?

6. SOLID Principles?:

   • Single Responsibility: Ek hi job mein checkout, read, compare, release, config, cleanup... sab ghusa diya.
   • Isse better hai ki cleanup aur release ko alag jobs mein rakho.

7. Documentation?:

   • Zero comments. Ek naya developer aayega toh sochega 'Configure Git' kyun kiya jab kuch commit hi nahi ho raha.

8. Technical Debt:

   • fetch-depth: 0 is future debt. Repo grow hogi, workflow slow hoga, fir koi aur aake isse fix karega. Tum kachra faila ke ja rahe ho.

9. Consistency Gap:

   • softprops/action-gh-release@v1 use kar rahe ho jabki v2 out hai. Purana version kyun? Purani yaadein taaza kar rahe ho?

10. Final Verdict on Quality:

    • Code padh ke lag raha hai ki 'Bas chal jaye' wali mentality hai. 'Aesthetic' aur 'Logic' dono missing hain.

Ab jao aur isse theek karo, warna agle review mein isse bhi bura roast karunga.

---

Generated by Review Buddy | Tone: roast | Language: hinglish

[github-actions]

⚠️ Review Buddy - Final Recommendation

👥 Attention: @AnkanSaha @Copilot

Recommendation: REQUEST CHANGES

Changes chahiye, bhai! Abhi approve nahi kar sakte.

Reasoning:

• The use of 'fetch-depth: 0' is inefficient and unnecessary for a simple version-based release unless full history is explicitly needed for changelogs.
• The 'Configure Git' step is redundant as there are no subsequent git commits or tags being pushed manually in the shown diff.
• The GITHUB_TOKEN is passed redundantly and without granular permissions, posing a minor security risk.
• The workflow lacks validation for the version string format (SemVer check missing).
• Release naming was simplified to just the version number, which might lack professional context compared to 'Release vX.Y.Z'.

---

📋 Review Checklist for Reviewers:

• Code changes align with the PR description
• No security vulnerabilities introduced
• Performance considerations addressed
• Code follows project conventions
• Tests are adequate (if applicable)
• Documentation updated (if needed)

🎯 Next Steps:

⚠️ Pehle suggestions address karo, phir approve karna.

Generated by Review Buddy | Tone: roast | Language: hinglish

[AnkanSaha]

/buddy yeh mailny banaya gya kyuki, mujhe directly publish karna hai, jab bhi pr merge hoga main pe

[github-actions]

@AnkanSaha Arre wah @AnkanSaha! 'Directly publish' karna hai? Ye toh wahi baat ho gayi ki 'Bhai ko pilot banna hai' par cycle chalani bhi nahi aati.

Sun, tera 'intent' toh humein PR title se hi samajh aa gaya tha, par tera 'implementation' abhi bhi kisi saste crash course jaisa lag raha hai.

1. Git Config ka Achar Daloge?: Tune Configure Git step add toh kar diya, par niche na git commit hai, na git push. Bhai, jab CLI se kuch kar hi nahi rahe, toh configuration kyun set kar rahe ho? Ye toh wahi baat hui ki helmet pehen ke so gaye ki kahin sapne mein accident na ho jaye.
2. fetch-depth: 0 ka Over-acting: 'Directly publish' karne ke liye tujhe poori sadiyon ki history kyun chahiye? fetch-depth: 1 se bhi release notes ban jate hain agar sahi se configure karo. Runner ka time aur bandwidth aise fook rahe ho jaise baap ka paisa ho.
3. Security ka Sannata: Global GITHUB_TOKEN pass karke tune security ki aisi-taisi kar di hai.

Bhai, directly publish karo ya indirectly, code 'kachra' nahi hona chahiye. Pehle ye redundant steps hata aur permissions set kar, phir hi approve milega. Logic lagao, shortcuts nahi!

Generated by Review Buddy | Tone: roast | Language: hinglish

[Copilot]

Pull request overview

Updates the project’s tracked version and adjusts the GitHub Actions auto-release workflow to better support release creation on version bumps.

Changes:

• Bump VERSION from v4.12 to v4.13.
• Update the auto-release workflow checkout behavior (full history) and tweak release title/body formatting.
• Add explicit GITHUB_TOKEN usage for the release step and add a Git configuration step.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
VERSION	Bumps the tracked version to v4.13.
.github/workflows/auto-release.yml	Adjusts checkout depth/token usage, changes release naming/body header, and adds token/env + git config steps for release/cleanup.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Checking out ref: main in a pull_request-closed workflow can make the release non-deterministic if additional commits land on main between the merge event and this job running. Prefer checking out the merged commit from the event payload (e.g., github.event.pull_request.merge_commit_sha) so the VERSION you read and the old-version comparison are based on the exact merge that triggered the workflow.

Suggested change

	ref: main
	ref: ${{ github.event.pull_request.merge_commit_sha }}

[Copilot]

The step name says "Checkout PR branch (merged code)", but this uses ref: main. Consider renaming this step to reflect what is actually checked out (or update the ref per the merge commit) to avoid confusion during debugging.