Fix syncbot workflow to run on pull_request events

[diegolovison]

Fix #415

[diegolovison]

@edeandrea this should save us a lot of time

[edeandrea]

I'd like @holly-cummins to take a look at this since she was the one working on the cross-branch automation.

Whats the purpose of README-otel.md?

[diegolovison]

Ops. Done

[holly-cummins]

I've been thinking about how we only run trusted workflows. I can think of a few options:

• Put a wait and then an extra check in the syncbot to not raise a PR until it can see a workflow is running for the original PR (it can't use the workflow as the trigger because it won't run, to avoid workflow storms)
• Adjust our repo settings to always require manual workflow approval for the syncbot user, but that would add an extra, annoying, step
• Check the permissions of the author of the original PR (although I'm not sure how easy that is), and then ... maybe mark the child PR as draft if it's not from a trusted author? Ideally we'd make the PR itself require manual approval but I don't think github allows that

[edeandrea]

I've been thinking about how we only run trusted workflows. I can think of a few options:

• Put a wait and then an extra check in the syncbot to not raise a PR until it can see a workflow is running for the original PR (it can't use the workflow as the trigger because it won't run, to avoid workflow storms)
• Adjust our repo settings to always require manual workflow approval for the syncbot user, but that would add an extra, annoying, step
• Check the permissions of the author of the original PR (although I'm not sure how easy that is), and then ... maybe mark the child PR as draft if it's not from a trusted author? Ideally we'd make the PR itself require manual approval but I don't think github allows that

I know we wanted more of an "opt out" vs "opt in" approach, but maybe we go back to the labelling thing? Someone with correct permissions to assign labels (triage?) has to label the PR to be "synced", and that is what gives syncbot the permission to do so? That way someone with the permissions has reviewed and said "this PR is ok"?

[holly-cummins]

I've been thinking about how we only run trusted workflows. I can think of a few options:

• Put a wait and then an extra check in the syncbot to not raise a PR until it can see a workflow is running for the original PR (it can't use the workflow as the trigger because it won't run, to avoid workflow storms)
• Adjust our repo settings to always require manual workflow approval for the syncbot user, but that would add an extra, annoying, step
• Check the permissions of the author of the original PR (although I'm not sure how easy that is), and then ... maybe mark the child PR as draft if it's not from a trusted author? Ideally we'd make the PR itself require manual approval but I don't think github allows that

I know we wanted more of an "opt out" vs "opt in" approach, but maybe we go back to the labelling thing? Someone with correct permissions to assign labels (triage?) has to label the PR to be "synced", and that is what gives syncbot the permission to do so? That way someone with the permissions has reviewed and said "this PR is ok"?

I had a conversation with Claude, and it also suggested labelling, but I think we can do it in a way that's less opt-in. #423 adjusts the normal workflow to use labels + repo membership to control what workflows run. So I think with that, we should be good on syncbot.

And of course the security concern I've identified was always there, I just didn't notice it until I was staring at @diegolovison's changes.

[holly-cummins]

Interestingly, the sync workflow is now running on this PR, even without @diegolovison's changes being merged.

The failure is

Run git config user.name syncbot
From https://github.com/quarkusio/spring-quarkus-perf-comparison
 * [new branch]      main       -> origin/main
 * [new branch]      ootb       -> origin/ootb
Source branch: fix_415
Target branch: ootb
Sync branch: sync-fix_415-to-ootb
Previous HEAD position was 58ef3da Merge 696510798d4beb7cdaf2f4d1261ed3038bc09c49 into 9b29e5ea1fb4a00d49cf8e876108d17adb85267a
Switched to a new branch 'sync-fix_415-to-ootb'
branch 'sync-fix_415-to-ootb' set up to track 'origin/ootb'.
fatal: ambiguous argument 'origin/ootb..origin/fix_415': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:

Will try to fix.

[holly-cummins]

The CI for this is now in a bit of a mess, because I've rebased several times and it's having conflicts while cherry-picking. That situation is something that should be handled, but I don't think it needs to be handled before merging this PR. I think it's an issue that will mostly affect PRs that stay open for a while and get rebased several times.