ci: fix to make pr label job required check

[psschwei]

Misc PR

Type of PR

• Bug Fix
• New Feature
• Documentation
• Other

Description

• Link to Issue: Fixes

This PR adds a small fix to the add labels / PR title action to enable us to use it as a required check.
Currently actions need to pass twice, once on the actual PR and then again when in the merge queue.
To make a check required, it has to pass in both phases.
The problem we had was the job would not return a result in the merge queue, meaning that if it was required it would prevent merging.
Here we add a small fix so that the job will pass in both phases.

Testing

• Tests added to the respective file if code was changed
• New code has 100% coverage if code as added
• Ensure existing tests and github automation passes (a maintainer will kick off the github automation when the rest of the PR is populated)

[github-actions]

The PR description has been updated. Please fill out the template for your PR to be reviewed.

[ajbozarth]

I guess this is fine, but I don't exactly see why it is needed though. If it passed on PR shouldn't it pass on merge?

[psschwei]

I don't exactly see why it is needed though. If it passed on PR shouldn't it pass on merge?

Unfortunately not. Had to wait for the update-pr-body action to finish so I could add the explanation why

[ajbozarth]

Unfortunately not. Had to wait for the update-pr-body action to finish so I could add the explanation why

IIUC this is needed because when in the merge queue it can't see the PR title and would auto-fail?

[psschwei]

IIUC this is needed because when in the merge queue it can't see the PR title and would auto-fail?

Not exactly, it's because when GitHub's merge queue processes a PR, it creates a temporary merge branch (e.g. gh-readonly-queue/main/...) and runs checks against it. This triggers push or merge_group events — not pull_request_target. So the pr-label workflow simply never runs when a PR enters the queue, meaning it never reports a status check, and the branch protection rule requiring it to pass can't be satisfied.

And we couldn't just add merge_group as one of the triggers for the existing job, because context.payload.pull_request doesn't exist in a merge_group event — the script would crash trying to read .title from it. The merge queue operates on a temporary branch, not a PR object, so the payload structure is different.