Git Clone Repository v4.0.6

We released a new version (4.0.6) of Git Clone Repository step.

Changes:

  • In case of manual merge clone pull/x/head branch then merge instead of cloning the pull/x/merge branch
  • Set inputs to read-only
  • fetch tags when cloning a tag
2 Likes

One side-effect of the new cloning strategy is that PRs that have merge conflicts with master can not be cloned. It would be nice to have the option for the step to fall back to the previous cloning strategy in that case.

Fro exemple check out this build https://www.bitrise.io/build/866115f0e30c0566

Hi @paour,

That’s actually not a side effect, that was a bug in the previous versions, related to how github provides the “pre-merge” branch.

GitHub changed how they handle the update of those pre-merge branches, and that’s why we switched from that in v4 of the Git Clone step as it’s no longer reliable. In short they only update it if you check the PR page manually, so if you just push a new commit and don’t open the PR page in your browser the pre-merge branch won’t be updated.

So, I believe what you describe as the “previous cloning strategy’s result” in v3 of the step, github simply did not update the pre-merge branch in case of a merge conflict. Meaning, the PR build (which is expected to test the pre-merge state of the code) was running on the latest version of the code before the merge conflict, not on the state which caused the conflict. Which is quite useless and even misleading.

With v4 of the step, and with the default configs of the step this is no longer an issue, as the step no longer relies on any special github feature, it performs the merge itself. :wink:

If that’s the case (that Github and the v3 clone step led to builds that did not reflect the latest state of the branch), that was indeed very bad. I never noticed.

So what’s your suggestion to keep Bitrise from failing builds when the branch a PR is based on is in conflict with the PR’s target?

When there’s a merge conflict the build / Git Clone step will fail in a pull request build, as it can’t merge the two. Pull Request builds are meant to test pre-merge code, the state you’d get after you merge the PR, to test it before you merge it and to report whether it’s safe to merge it or not. When there’s a merge conflict it’s not safe to merge :slight_smile: