Description
Description
tl;dr: When using a CI configuration set up with on: pull_request
, this fires on PR updates, but checks out not the merge commit, but the PR HEAD.
This is unexpected, because
- This behaviour differs from Github's
- This makes it harder to do Continuous Integration, as the PR does not get tested as integrated into the target branch.
Observed behaviour
As documented, Gitea Actions implement the pull_request
workflow trigger event, and it is "compatible with Github".
Githubs docs, linked from the above page, say that GITHUB_SHA
will be the "Last merge commit on the GITHUB_REF branch" and GITHUB_REF
will be the "PR merge branch refs/pull/:prNumber/merge".
I have a workflow configured with
on:
push:
branches:
- main
pull_request:
and use actions/checkout@v3
.
On a pull request update, in the "Set up job" log of the Workflow run, I unexpectedly see "GITHUB_REF:refs/pull/61/head" and a GITHUB_SHA entry that corresponds to the PR HEAD (i.e. the last pushed commit), and not the merge commit, as documented.
Expected behaviour
A pull_request
event builds the merge commit of the PR commit that triggered the event, or some other way to continuously build the integrated branch. Otherwise a PR could test green, but break the tests after merging.
Gitea Version
1.20.3
Can you reproduce the bug on the Gitea demo site?
Could not check
Log Gist
No response
Screenshots
No response
Git Version
No response
Operating System
No response
How are you running Gitea?
This is a self-hosted instance, but I'm not running it so I can't offer more details.
Database
None