chore(ci): make Guard main branch re-evaluate on base changes

[mateo-berri]

Summary

Guard main branch (.github/workflows/guard-main-branch.yml) currently uses pull_request.branches: [main] to gate execution. That filter only matches when the PR's current base is main. When a PR is opened against main and later retargeted (e.g. to litellm_internal_staging), the workflow does not refire, so the earlier failed run sticks on the PR even though the branch-name rule no longer applies. This bit #27775, where the PR was briefly opened against main before flipping to litellm_internal_staging.

Fix

Drop the branches: [main] filter, add edited to types so base changes retrigger the workflow, and short-circuit inside the job when github.base_ref != main. Main-targeted PRs still get the existing head-repo and branch-name checks unchanged; non-main PRs exit cleanly in a few seconds, and a base flip away from main produces a fresh passing run that supersedes the old failing status on the PR.

Job name (Verify PR source branch) is preserved, so the existing branch-protection requirement on main keeps working.

Files touched

• .github/workflows/guard-main-branch.yml — adjust trigger to listen on all PR events (opened, synchronize, reopened, edited), add BASE_REF to env, exit 0 early when base != main.

Test plan

• YAML diff is minimal — only the trigger filter and a new base-ref guard at the top of the script
• Once merged, this PR's own run on litellm_internal_staging should pass (base != main short-circuit). If we ever rebase another PR onto main and back, the run history on the PR should end on a green status

Type

🛠️ CI / Infra

---

Note

Low Risk
Low risk: only adjusts a GitHub Actions workflow trigger and adds an early-exit for non-main PR bases, without changing application/runtime code paths.

Overview
Updates the Guard main branch GitHub Actions workflow to re-evaluate when a PR’s base branch changes by listening to additional pull_request event types (including edited) instead of filtering on branches: [main].

Adds a github.base_ref check inside the job to skip the guard (exit 0) when the PR is not targeting main, while keeping the existing fork and source-branch restrictions for PRs that do target main.

^{Reviewed by Cursor Bugbot for commit 8358c9a. Bugbot is set up for automated code reviews on this repo. Configure here.}

[greptile-apps]

Greptile Summary

This CI-only change fixes a stale failed-check problem: when a PR was opened against main and then retargeted to another branch, the old failing Verify PR source branch run remained attached to the PR. The fix broadens the trigger to all PR event types (including edited), then short-circuits with exit 0 when the base branch is not main, ensuring a fresh passing run supersedes the stale failure.

• Drops branches: [main] and adds types: [opened, synchronize, reopened, edited] so base-branch edits retrigger the workflow.
• Injects BASE_REF into the shell step and exits 0 immediately for any non-main target, keeping non-main PR runs cheap and always green.
• The job name: Verify PR source branch is intentionally preserved to keep the existing main branch-protection status-check requirement intact.

Confidence Score: 5/5

Safe to merge — the change is narrowly scoped to the CI trigger and an early-exit guard; main-targeted PRs go through the same fork and branch-name checks as before.

The diff is minimal: one trigger-filter swap and a four-line shell guard. The job name is preserved, so branch protection on main is unaffected. Non-main PRs exit cleanly in seconds; main-targeted PRs reach the same validation logic as before. No application code, tests, or security controls are touched.

No files require special attention.

Important Files Changed

Filename	Overview
.github/workflows/guard-main-branch.yml	Removes branches: [main] trigger filter, adds edited event type, and inserts a BASE_REF != main early-exit guard so the workflow re-runs cleanly when a PR is retargeted away from main.

_{Reviews (1): Last reviewed commit: "style: remove unneeded comments" | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[devin-ai-integration]

🚅 Hi, thanks for the PR! I'm Agent Shin, the automated triage bot for this repository. What's this and why am I getting it?

I read the description against our contribution rubric. Here's how it lined up:

What you got right:

• ✅ Linked a related GitHub issue
• ✅ Clear problem description
• ✅ Expected vs. actual behavior

What's still missing:

• end-to-end QA proof (video, screenshot, or real commands with output)

The PR clearly describes the bug and expected behavior, and it links a related issue, so context is present. However, the body contains no end-to-end QA evidence—only a test plan and assertions—so it fails the contribution standard.

If the description isn't updated in the next 24 hours, I'll auto-close this PR. That's not us saying we don't care about the change; we want the open-PR list to mirror what a maintainer can act on right now, so contributors don't get lost in a backlog. A closed PR is a soft "park this for later," not a rejection. Take your time; everything below still works after the close.

During the grace period: just update the PR description with the missing pieces. No need to ping me; I'll re-check on the next sweep and skip the auto-close if it now passes. See what counts as QA proof for the full rubric (a linked issue alone isn't enough; it covers context, not proof).

If the PR does get auto-closed in 24 hours, you still have easy recovery paths:

• Comment @agent-shin reconsider after updating the description. I'll re-evaluate and reopen the PR if it now passes.
• Comment @greptileai to request a fresh Greptile review; that still works even after the PR is closed, and a stronger score is one of the signals that lifts the PR back into the queue. So a low Greptile score isn't a blocker either.

Internal BerriAI contributors: this rubric doesn't apply to you; ping a maintainer.

(I'm an LLM, so I'm not infallible. If you think I got this wrong, ping a maintainer; they'll override me.)