v3 on: [pull_request] doesn't actually check out branch, it rather checks out a version merged/based on top of the target branch, including changes from the target branch

[thisismydesign]

Similar/same as
#237
#299
#626
#504

This issue isn't resolved on v3. It's very unexpected that instead of checking out the actual code I'm working on in the PR, the CI runs on a completely different code. I.e. code from the target branch will be included in the checked-out code. Can this even produce consistent behavior? What happens in case of conflict with the target branch?

GitHub has a feature to enforce keeping PRs up to date for those who wish to do so

I opened a new issue because the others were either closed as fixed, or the titles were not descriptive and there were no comments from maintainers. Can we explain whether this is even expected behavior?

[KalleOlaviNiemitalo]

#112 added documentation on how to avoid the merge: https://github.com/actions/checkout/blob/v3.0.2/README.md#user-content-checkout-pull-request-head-commit-instead-of-merge-commit

[thisismydesign]

Thanks, so it's expected behavior. In that case, I'm asking to change it.

What happens in case of conflict with the target branch?

Meanwhile, I discovered that the CI would not run in this case. This is also a big drawback. Firstly it's unexpected and takes time to figure out why. But more importantly, I rely on the CI to run. E.g. I might run some checks (e.g. unit test) locally but would expect the CI to tell me if my changes integrate well with other parts of the software. Now I have to resolve conflicts every time as soon as they occur so that I can continue development? Awful.

[KalleOlaviNiemitalo]

I'm curious, how did you start using the checkout action in your workflow; did you copy the workflow from a template? If so, perhaps the template could be improved by adding some comments to explain the behaviour.

[thisismydesign]

@KalleOlaviNiemitalo Found it in a project I started to work on :)

There are many reasons to use on: pull_request trigger (instead of on: push), e.g.

• Will trigger on contributions from forks, without the contributor having to enable actions on their fork (and potentially use their own CI minutes)
• You can push WIP state without triggering the CI
• Run things only on feature branches without the need to explicitly restrict branches

But that's beside the point I think. The point is that this is very surprising (as evidenced by the issues linked above) and therefore this probably isn't the right way to go about it. https://en.wikipedia.org/wiki/Principle_of_least_astonishment

[mattsh247]

why am i getting these notification's I recently was hacked and found many accounts in my name. Does this have anything to do with that?

…

-----Original Message----- From: Csaba Apagyi ***@***.***> To: actions/checkout ***@***.***> Cc: Subscribed ***@***.***> Sent: Wed, Aug 17, 2022 4:53 am Subject: Re: [actions/checkout] v3 `on: [pull_request]` doesn't actually check out branch, it rather checks out a version merged/based on top of the target branch, including changes from the target branch (Issue #881) Thanks, so it's expected behavior. In that case, I'm asking to change it. What happens in case of conflict with the target branch? Meanwhile, I discovered that the CI would not run in this case. This is also a big drawback. Firstly it's unexpected and takes time to figure out why. But more importantly, I rely on the CI to run. E.g. I might run some checks (e.g. unit test) locally but would expect the CI to tell me if my changes integrate well with other parts of the software. Now I have to resolve conflicts every time as soon as they occur so that I can continue development? Awful. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.

[sidekick-eimantas]

I'm trying to get the list of files modified since main branch on pull request, in python code, and because of the checkout behaviour of this action I've now been stuck on the problem for like 4 hours.
fatal: Not a valid object name main
fatal: ambiguous argument 'main': unknown revision or path not in the working tree.
etc..

The solution @KalleOlaviNiemitalo mentions above does not work.

[KalleOlaviNiemitalo]

To clarify: I got here from dotnet/Nerdbank.GitVersioning#796 (comment) and am not using this action myself.

[dlupu]

Having similar issues on a private project, the checked-out code in the github action is not the code of the commit that has triggered the CI.

Same use case (v3 on: [pull_request] )

[nahojs]

I had similar issues but came up with this solution after some extensive digging. If checking out code using actions/checkout@v3 and trigger is pull_request the ref parameter needs to be github.event.pull_request.head.ref (for push use github.ref) Depth is default 1 (shallow clone), so try different values. 0 is full history. Complete example:

env:
  MY_REF: ${{ format('refs/heads/{0}', github.event.pull_request.head.ref) }}

[..]
     - name: Checkout Requests
          uses: actions/checkout@v3
          with:
            repository: My.Repo
            ref: ${{ env.MY_REF}}
            fetch-depth: 0

[janderssonse]

If there are technical issues fine, but in all other aspects (as issues tell), the expected behaviour for a user would be as the @thisismydesign described it, (the different users reporting issues about it this tells the same story). As an user I would expect it to checkout the latest code on a pr - i also had to do a workaround with refs explicitly. Anyway, thanks for the action!!

[giuliano-macedo]

I think the issue is with github actions itself and not with the checkout action, since the checkout action uses by default the equivalent of {{github.sha}} which is the default branch for that trigger, and so for pull request trigger it does this merging before hand and results in this weird behavior.