fix: add permissions and git config for semantic-release

[adslaton]

🔧 Fix: Semantic Release Permissions

Fixes the error in the semantic-release workflow.

🐛 Problem

The semantic-release workflow was failing with:

This occurred because the default lacked sufficient permissions to push tags and commits back to the repository.

✅ Solution

1. Added explicit permissions to the workflow:

   • • for pushing commits and tags
   • • for creating releases
   • • for release notes

2. Configured Git credentials properly:

   • Set git user as
   • Configure remote URL with GitHub token
   • Use in checkout for security

🧪 Testing

• ✅ YAML syntax validates
• ✅ Follows GitHub Actions best practices
• ✅ Uses conventional commit format for this fix

This should resolve the permissions issue and allow semantic-release to properly create releases with version tags.

[github-actions]

🔒 Security Scan Results

✅ npm audit - Dependency Security

No vulnerable dependencies found.

⚠️ audit-ci Security Check

No results file generated.

⚠️ ESLint Security Analysis

No results file generated.

---

✅ All security scans passed! No issues found.

[github-actions]

🤖 AI Review

Of course. Here is a detailed review of the pull request.

---

Pull Request Review: 🔧 Fix: Semantic Release Permissions

Summary of Changes

This pull request addresses a permissions failure in the semantic-release GitHub Actions workflow. The changes introduce an explicit permissions block at the workflow level to grant the necessary write access for contents, issues, and pull-requests. It also adds a dedicated step to configure Git with the github-actions[bot] user and correctly sets the remote URL with the GITHUB_TOKEN to allow pushing commits and tags. Finally, it sets persist-credentials: false in the checkout step for better security and control.

---

Strengths of the Implementation

1. Correct Diagnosis: The PR correctly identifies the root cause of the HttpError: Resource not accessible by integration error. Since March 2023, GitHub has tightened default permissions for GITHUB_TOKEN, and this PR implements the standard, recommended fix.
2. Principle of Least Privilege: By explicitly defining the required permissions (contents: write, issues: write, pull-requests: write), the workflow avoids granting overly broad permissions. It requests only what semantic-release needs to function fully.
3. Security Best Practices:
   • Using the short-lived GITHUB_TOKEN is much more secure than creating and storing a Personal Access Token (PAT) as a repository secret.
   • Setting persist-credentials: false in actions/checkout and then manually configuring the remote URL is a robust pattern. It ensures credentials aren't leaked into the git config file and gives explicit control over the authentication method.
4. Clarity and Maintainability: The addition of a separate, named step "Configure Git" makes the workflow's logic easy to follow. Future developers will immediately understand why Git is being configured manually.
5. Excellent PR Description: The description is a model of clarity. It explains the problem with the exact error message, details the solution, and outlines the testing performed. This significantly aids the review process.

---

Issues or Concerns

I have no major concerns with this implementation. The approach taken is the industry standard for solving this exact problem and is well-executed.

---

Suggestions for Improvement

While the PR is excellent, here are a couple of minor suggestions for further improvement:

1. Add Explanatory Comments: For future maintainability, consider adding a comment to the permissions block in the YAML file to explain why these specific permissions are needed.

   # .github/workflows/release.yml
   
   # These permissions are needed for the semantic-release bot to:
   # - contents: write    (push releases and tags)
   # - issues: write      (comment on issues)
   # - pull-requests: write (comment on pull requests)
   permissions:
     contents: write
     issues: write
     pull-requests: write

2. Verify Minimum Required Permissions (Optional): The permissions issues: write and pull-requests: write are used by the @semantic-release/github plugin to comment on related issues and PRs. If your team doesn't rely on this feature, you could potentially remove those permissions, further adhering to the principle of least privilege. However, keeping them is standard practice and often desired. This is more of a discussion point than a required change.

---

Review by Focus Area

• Code Quality and Best Practices: Excellent. The changes follow current GitHub Actions best practices for security and permissions.
• Potential Bugs or Issues: Low risk. This change fixes a known bug and is unlikely to introduce new ones. The implementation is solid.
• Security Concerns: None. The PR strengthens the security posture by using GITHUB_TOKEN correctly and scoping permissions explicitly.
• Performance Implications: Negligible. The new Configure Git step adds less than a second of execution time to the workflow.
• Test Coverage: Appropriate for a workflow change. The author has confirmed YAML syntax validation. The ultimate test is a successful run of the workflow on the main branch post-merge.
• Documentation Updates Needed: Unlikely. This is an internal fix to the CI/CD process. Unless you have a CONTRIBUTING.md or other developer documentation that details the (now-old) release process, no updates should be necessary.

---

Overall Recommendation

This is a well-researched and cleanly implemented fix for a common issue. The code quality is high, it follows security best practices, and the PR description is exemplary.

I recommend to Approve this pull request. It can be merged as is.

---

This review was automatically generated by google/gemini-2.5-pro via OpenRouter. Please consider it as supplementary feedback alongside human review.