Detect merge conflicts early

How To
1

I added a script in my workflow, to make merge conflicts visible early in the development process. Perhaps this can help others too.

For each commit, I’d like to know if it could cause merge conflicts to (in my case) develop . So at the end of my normal workflow where I run the unit tests, I check out the develop branch, try to merge the changed branch, and run unit tests on the result.
This helps me to find merge conflicts sooner in our development process.

Here is the script build step that works for me:

#!/usr/bin/env bash
# fail if any commands fails
set -e
# debug log
set -x

TARGET_BRANCH="develop"
SOURCE_BRANCH="$BITRISE_GIT_BRANCH"

git reset --hard

git "checkout" "$SOURCE_BRANCH"

git merge "origin/$SOURCE_BRANCH"

git fetch "origin" "$TARGET_BRANCH"

git reset --hard
git checkout origin/$TARGET_BRANCH
git merge $SOURCE_BRANCH
3 Likes
2

Thanks for sharing this here as well @jpalten!

3

It just occurred to me that I should do the same, and here’s the answer. Thanks for saving me some time :slight_smile:.

2 Likes
4

Actually Bitrise Pull Request builds do the same automatically: it clones the target (the one the PR/MR is meant to be merged into) then it git merges the source onto it.

Of course this only works for Pull Requests/Merge Requests and only if you enable the pull request triggers to be built (https://devcenter.bitrise.io/builds/triggering-builds/trigger-map/), but in that case it should be automatic.

If that would not be the case let me know!

P.S.: You can see the git commands performed in the Git Clone step’s build logs, e.g.:

git "init"
Initialized empty Git repository in /bitrise/go/src/github.com/bitrise-io/bitrise/.git/
git "remote" "add" "origin" "https://github.com/bitrise-io/bitrise.git"
git "fetch" "origin" "master"
From https://github.com/bitrise-io/bitrise
 * branch            master     -> FETCH_HEAD
 * [new branch]      master     -> origin/master
git "checkout" "master"
Already on 'master'
Branch master set up to track remote branch master from origin.
git "merge" "origin/master"
Already up-to-date.
commit hash: 7850cc59ebb20fee59ffca4b21b739cf561f3579
git "fetch" "origin" "godrei-patch-1"
From https://github.com/bitrise-io/bitrise
 * branch            godrei-patch-1 -> FETCH_HEAD
 * [new branch]      godrei-patch-1 -> origin/godrei-patch-1
git "merge" "9d704732ce1cc27de14f48b16d6043572cfe86be"
Updating 7850cc5..9d70473
Fast-forward
 README.md | 13 -------------
 1 file changed, 13 deletions(-)
git "submodule" "update" "--init" "--recursive"
git "checkout" "--detach"

(https://github.com/bitrise-io/bitrise/pull/653 's build)

6

How do I stop it trying to merge to develop if the build was triggered due to a pull request?

I just want Bitrise to build the branch, and develop may have changed so the merge will fail, erroneously failing the build.

7

@ben.thomas to not to test the PR merge you can trigger the build for the push event and remove it from pull_request event

To trigger builds for code push for all branches:

trigger_map:
- push_branch: *
  workflow: primary

To trigger different workflows for named branches, e.g. for main and another workflow for every other push:

trigger_map:
- push_branch: main
  workflow: deploy
- push_branch: *
  workflow: primary

If you remove the Pull Request items from the Trigger Map then no pre-merge will be performed.
You can do it on the web UI as well, but in the YML I’m referring to these as pull request items in the trigger map:

- pull_request_target_branch: "master"
  pull_request_source_branch: "develop"
  workflow: primary

That said, in general it’s a best practice to test the pre-merge state, as that’s what the state of the code will be after you merge the PR.

8

Thank you for the suggestions @viktorbenei