chore: add automerge pipeline

[SamTV12345]

No description provided.

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

Review Summary by Qodo

Add Dependabot automerge GitHub Actions workflow

✨ Enhancement

Walkthroughs

Description

• Adds GitHub Actions workflow for automatic Dependabot PR merging
• Configured to automerge when tests pass using squash merge
• Triggers on pull request open, synchronize, and reopen events

Diagram

flowchart LR
  A["Dependabot PR"] -- "opened/synchronize/reopened" --> B["Automerge Workflow"]
  B -- "if actor is dependabot[bot]" --> C["Squash Merge PR"]
  C -- "with retry logic" --> D["PR Merged"]

Loading

File Changes

1. .github/workflows/automerge.yml ⚙️ Configuration changes +26/-0

New Dependabot automerge workflow configuration

• Creates new GitHub Actions workflow for automatic Dependabot PR merging
• Configures job to run only for Dependabot pull requests
• Uses pascalgn/automerge-action@v0.16.4 with squash merge strategy
• Sets retry sleep to 100000ms for merge attempts

.github/workflows/automerge.yml

---

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

Code Review by Qodo

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

🐞\ ⛨ Security (1)

1. Unpinned action versions 🐞 ⛨

Description

The workflow runs actions from mutable tags (not immutable commit SHAs) while granting write
permissions, so a compromised/retargeted tag could execute attacker-controlled code with repository
write access. This is especially risky for the third-party automerge action that receives
GITHUB_TOKEN with write permissions.

Code

.github/workflows/automerge.yml[R2-23]

+permissions:
+  contents: write
+  pull-requests: write
+on:
+  pull_request:
+    types:
+      - opened
+      - synchronize
+      - reopened
+
+jobs:
+  automerge:
+    if: github.actor == 'dependabot[bot]'
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Automerge
+        uses: "pascalgn/automerge-action@v0.16.4"
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Evidence

The workflow grants write permissions and then executes actions pinned only to tags, not commit
SHAs.

.github/workflows/automerge.yml[2-4]
.github/workflows/automerge.yml[17-23]

Agent prompt

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

## Issue description
This workflow uses mutable action tags (e.g., `@v4`, `@v0.16.4`) while running with `contents: write` / `pull-requests: write`. If an action tag is compromised or retargeted, the workflow could run untrusted code with write access.
### Issue Context
The risk is higher for third-party actions receiving `GITHUB_TOKEN` with write permissions.
### Fix Focus Areas
- .github/workflows/automerge.yml[2-4]
- .github/workflows/automerge.yml[17-23]
### Suggested fix
Update `uses:` to pin each action to an immutable commit SHA (optionally keeping the tag in a comment for readability), e.g.:
- `uses: actions/checkout@<full_sha>`
- `uses: pascalgn/automerge-action@<full_sha>`

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

---

2. No explicit CI merge gate ☑ 🐞 ☼

Description

The automerge workflow runs on pull_request events and immediately attempts to merge, but it does
not explicitly wait for the repository’s CI workflow to complete/succeed. As a result, “merge only
if tests pass” is not enforced by this workflow itself and instead depends on external branch
protection/required-check configuration.

Code

.github/workflows/automerge.yml[R5-10]

+on:
+  pull_request:
+    types:
+      - opened
+      - synchronize
+      - reopened

Evidence

CI is defined as a separate workflow that runs on pull_request, while the new automerge workflow
also runs on pull_request and contains no workflow_run-based gating or other explicit dependency
tying the merge attempt to CI completion.

.github/workflows/automerge.yml[5-10]
.github/workflows/automerge.yml[20-26]
.github/workflows/ci.yml[3-7]

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 automerge workflow triggers on PR events and attempts to merge without an explicit guarantee that the repo CI workflow has finished and succeeded. This makes the “tests pass” requirement implicit (branch protection) rather than enforced in the workflow.
### Issue Context
The repo already has a PR CI workflow (`.github/workflows/ci.yml`) that runs on `pull_request`.
### Fix Focus Areas
- .github/workflows/automerge.yml[5-10]
- .github/workflows/automerge.yml[20-26]
- .github/workflows/ci.yml[3-7]
### Suggested fix
Switch the automerge trigger to `workflow_run` for the CI workflow and only run when the CI conclusion is `success`, e.g.:
- `on: workflow_run: workflows: ["CI"] types: [completed]`
- job-level `if: github.event.workflow_run.conclusion == 'success' && github.actor == 'dependabot[bot]'` (or check the PR author from the workflow_run payload)
Alternatively, add explicit status/check validation before merging (but ensure it is implemented in-repo so the merge gate is deterministic).

ⓘ 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