ci: fix PR title ci job concurrency

[dimaqq]

https://matrix.to/#/!eNCNzcteYUDDYpStsu:ubuntu.com/$PjGy1bizJkNGgu-A629wckDFKPzEQ5BKXIkmlE8sUyg?via=ubuntu.com&via=matrix.org

Huh, looks like we have a small bug in the CI:

Canceling since a higher priority waiting request for 'Validate PR Title-refs/heads/main' exists

which happened for this PR: #1447

surely the concurrency group should not be set to "main" for a new PR, should it?

[dimaqq]

I was thinking to use branch names first, but what if both tony and david issue a PR from their forks' main?
github.event.pull_request.number seems to be canonical on Stack Overflow, even if the .event feels like a private API.

[james-garner-canonical]

Interestingly, the documentation indicates that github.ref should be refs/pull/<pr_number>/merge for pull requests, which should be just as unique a event.pull_request.number, shouldn't it?

I can't find the documentation for event.pull_request.number, but I guess the value is that it gives you just the PR number if you want to do something with that.

[james-garner-canonical]

Ah, I see that for the linked PR where we had this issue, github.ref evaluated to refs/heads/main. The documentation says: 'for branches the format is refs/heads/<branch_name>, for pull requests it is refs/pull/<pr_number>/merge', so the dependabot PR isn't being treated as a PR in ci?

EDIT: or the documentation is just wrong?

[dimaqq]

Interestingly, the documentation indicates that github.ref should be refs/pull/<pr_number>/merge for pull requests, which should be just as unique a event.pull_request.number, shouldn't it?

Bad docs.

I think they meant to say "for a pull request merge event," or something alike.

It's clearly the base branch for outstanding pull requests in the context of the pull_request_target event.

I guess _target is kinda magical anyway.

Or, rather, target is reasonable, but plain PR event is magical, because if the base branch has moved on, GitHub will make a "fake merge" (what you'd get if you merged the PR right now) to run the action against, and if there's no clean fake merge, it'd run against "fake merge against base" or something like that. Convoluted.