fix(workflows): run backport in base repo context

[ayagmar]

Description

Follow-up for the backport workflow #14496

Switches the trigger from pull_request to pull_request_target and checks out the base branch ref explicitly. The dry-run behavior looked correct, however the execution needs base-repo context so GitHub Actions can push the backport branch and open the PR for cross-repo merges ( forks )

[rmuir]

We will need to find a more secure method than pull_request_target

[ayagmar]

We will need to find a more secure method than pull_request_target

Hmm do you have any recommendations?
I can trigger the backport on push to main instead of pr events, would you prefer this?

[rmuir]

Hmm do you have any recommendations?
I can trigger the backport on push to main instead of pr events, would you prefer this?

I don't have any specific recommendations, but too many open source projects are getting hacked via pull_request_target, so i think we really need to avoid opening up a vector for trouble here.

push to main sounds much better!!

[ayagmar]

Hmm do you have any recommendations?
I can trigger the backport on push to main instead of pr events, would you prefer this?

I don't have any specific recommendations, but too many open source projects are getting hacked via pull_request_target, so i think we really need to avoid opening up a vector for trouble here.

push to main sounds much better!!

I agree and sorry about that haha, I've also been seeing the pwns and it's getting scary

[ayagmar]

Done i did the changes
Also tested it again on my a demo repo with labels + milestone + no-op on normal prs

no concerns anymore about pull_request_target, it uses push trigger now

[stefanvodita]

It feels like there's quite a few changes here besides changing the action trigger. We're still dry-running though, so this would be safe to test, right?

[rmuir]

To me this looks rewritten by LLM. I know it's all the rage, but I think we should avoid this for the ci. Can we please clean up after the llm and make minimal logic for this project? Many of the conditionals aren't even relevant

[ayagmar]

We're still dry-running though, so this would be safe to test, right?

Yes. same behavior with dry run naturally, this only plans and prints what it would do. It does not perform any actions

It feels like there's quite a few changes here besides changing the action trigger

That's true, and it's mainly because push does not have the PR context that pull_request had. We lose the PR number, labels, milestone, title, and merge SHA, so the workflow has to resolve pushed commits back to their merged PRs before it can decide whether to backport.

We also dropped the cherry-pick action. That action is built around PR-triggered context and points forked-repo usage toward pull_request_target, which we don't want here! so it means on push, the backport step had to become explicit.

To me this looks rewritten by LLM. I know it's all the rage, but I think we should avoid this for the ci. Can we please clean up after the llm and make minimal logic for this project? Many of the conditionals aren't even relevant

Fair criticism.

I did use LLMs while reviewing this before i pushed, and it ended up being more defensive than it should have been.. I went back through it with that in mind and trimmed out the parts that were not really justified or earned their keep

At this point, the parts I think are actually necessary are:

• walk the full pushed commit range
• resolve each merged PR from those commits
• use that PR metadata to decide targets
• perform the backport explicitly from the push context

@rmuir @stefanvodita If you think there's still a simpler shape here, I'm very open to it and thank you for reviewing

[github-actions]

This PR has not had activity in the past 2 weeks, labeling it as stale. If the PR is waiting for review, notify the dev@lucene.apache.org list. Thank you for your contribution!