chore(brancing): Warn targeting main

[gjanco]

Add a warning to a PR targeting main as AURA references the mezmo branch of RIG.

Ref: https://github.com/mezmo/aura/blob/main/docs/rig-fork-changes.md

[greptile-apps]

Greptile Summary

Adds a narrowly permissioned pull_request_target workflow that warns contributors when a pull request targets main instead of mezmo.

• Uses a commit-pinned GitHub Script action.
• Avoids checking out or executing untrusted pull-request code.
• Posts the retargeting guidance as a pull-request comment.

Confidence Score: 5/5

The PR appears safe to merge, although the existing non-blocking stale-warning behavior after retargeting remains.

The malformed GitHub Script from the resolved previous finding is fixed. The unresolved previous finding remains because the workflow still subscribes only to opened, so retargeting a pull request to mezmo neither reruns the check nor removes the earlier warning; this is non-blocking.

Important Files Changed

Filename	Overview
.github/workflows/pr-target-branch.yml	Adds the target-branch warning workflow; the prior syntax failure is fixed, while the previously reported opened-only retargeting limitation remains.

_{Reviews (3): Last reviewed commit: "chore(brancing): Warn targeting main" | Re-trigger Greptile}

[greptile-apps]

Retargeting leaves stale warnings

The workflow subscribes only to opened, although its comments say retargeting reruns the check and clears the warning. Changing the base branch emits an edited event, and the script has no logic to remove an earlier comment, so a pull request retargeted to mezmo would retain the stale warning.

[gjanco]

I deleted the comment. But would it be better to do something like resolving it like what is done in https://github.com/mezmo/aura/blob/main/.github/workflows/pr-target-branch.yml#L89

[greptile-apps]

Yes—Aura’s marker-based update is better than deleting the comment. It preserves the audit trail, avoids duplicate bot comments, and replaces the warning in place when the PR is retargeted.

It is not technically resolving a GitHub review thread; it finds the bot’s marker comment and updates it to a “Resolved” message. For Rig, use the same pattern:

Suggested change

	types: [opened]
	pull_request_target:
	types: [opened, reopened, edited]

Add a stable marker such as <!-- pr-target-branch -->, locate only the github-actions[bot] comment containing that marker, and update it to a resolved message when an edited event changes the base away from main. edited is the key event for retargeting; reopened covers a PR reopened while still targeting main. This maintains one warning comment per PR without leaving a stale warning.

Tip: You can customize Greptile's behavior for this repo with .greptile/rules.md and .greptile/config.json.

[dhable]

🚢

It could auto resolve the comment but we can also do that by hand. This should help with future changes/onboarding into the process with a low effort.