Invalid commit checked built on bitrise.io

[koral]

Bitrise Build Issue Report template

Description of the issue

Commit taken by bitrise.io was one before expected one. Rebuild fixed the issue.

Environment:

Where did the issue happen?

On Bitrise.io: Android Stack

Which build Step causes the issue and which version of the step?
git-clone 3.5.3 maybe

Reproducibility

• Does a “Rebuild” help? (You can trigger a rebuild from the Build’s page, by clicking the “Rebuild” button in the top right corner of a finished build) : YES
• Does a rebuild without caches help? (You can remove the Cache:Pull and Cache:Push steps temporarily to not to use the cache, or you can delete all the caches on the Settings tab of the app. : N/A
• If you have multiple different build configurations (workflows), does the issue affect all/more than one? : I haven’t checked
• If it’s an issue which happens sporadically, what’s the frequency? (e.g. Once a day ; about x% of the builds) : This is first confirmed occurrence
• Does upgrading the build Step to the latest version help? : NO
• When did the issue start? : Today

Linux/Android stack builds

Can it be reproduced by running the build locally, after doing a new git clone of the repository into the /tmp directory and running the build from there with the Bitrise CLI ( https://www.bitrise.io/cli )? If no, can it be reproduced with Docker (using the same docker images / environment we use on bitrise.io)? Related guide: http://devcenter.bitrise.io/docker/run-your-build-locally-in-docker/ .
N/A clone causes the issue

Build log

1. Build just before one which was failed unexpectedly:
   https://www.bitrise.io/build/ae39adae7348bad6
   Failure is expected here.
   Git clone log:

    Git Checkout Configs:
    - Commit: 4e018487acf61b54fd78848e6f9d5c8c11bf9ed2
    Exporting git logs
    => GIT_CLONE_COMMIT_HASH
       value: 926737fb15c7289638bac6d047050ea3544de96c
    => GIT_CLONE_COMMIT_MESSAGE_SUBJECT
       value: Merge 4e018487acf61b54fd78848e6f9d5c8c11bf9ed2 into 33cd0e304b5a24f44dffcec7c0e5ea0f46304bca

2. Build failed unexpectedly:
   https://www.bitrise.io/build/b75821cafca36f10
   Failure is not expected, error in source code which caused previous build failure has been fixed.
   Git clone log:

Git Checkout Configs:
- Commit: 40d0f187dea25ec88ed3bbd3474a9118103737ff
Exporting git logs
=> GIT_CLONE_COMMIT_HASH
   value: 926737fb15c7289638bac6d047050ea3544de96c
=> GIT_CLONE_COMMIT_MESSAGE_SUBJECT
   value: Merge 4e018487acf61b54fd78848e6f9d5c8c11bf9ed2 into 33cd0e304b5a24f44dffcec7c0e5ea0f46304bca

3. Previous build after rebuild, succeeded. Nothing has changed between 2. and 3. in source code nor in workflow.
   https://www.bitrise.io/build/b6c7515ce3d6f706
   Git clone log:

Git Checkout Configs:
- Commit: 40d0f187dea25ec88ed3bbd3474a9118103737ff
Exporting git logs
=> GIT_CLONE_COMMIT_HASH
   value: f2fdc3cfa294de71fcdf836d568e32a31c42437b
=> GIT_CLONE_COMMIT_MESSAGE_SUBJECT
   value: Merge 40d0f187dea25ec88ed3bbd3474a9118103737ff into 33cd0e304b5a24f44dffcec7c0e5ea0f46304bca

[viktorbenei]

We saw this too a few times - it seems this is a GitHub issue, that sometimes it fails to update the PR merge branch. This can only happen in case of GitHub PR builds as there we check out the GitHub provided /pr/merge branch, which should be the state of the code after it’d be merged.

Unfortunately it seems that GitHub sometimes in the last couple of weeks started to lag behind with the update of this merge branch…

A fix is already on our roadmap for this week, to do a full manual merge instead when possible, instead of relying on the github provided merge branch.

[viktorbenei]

Update: we released v3.6.x of the Git Clone step to solve this issue, by doing manual git merge instead of relying on the GitHub provided /merge branch to be up to date.

Unfortunately we hit a couple of edge cases and so we reverted the default “merge strategy” in the latest v3.6.2 version. That said, 3.6.2 should be safe to use even with the new manual merge strategy, but we’ll do another update ASAP which will address the discovered edge cases.

Git Clone Repository step v3.6.2

We released a new version (3.6.2) of Git Clone Repository step. Changes: Revert to 3.5.x github pr merge strategy by default (manual_merge: "no") while we’re tracking a couple of issues. If you want to opt in to the new merge strategy (introduced in 3.6.0) just set manual_merge to "yes".

As mentioned in the release notes to opt-in to the new merge strategy simply upgrade to v3.6.2 and change the manual_merge input option from "no" to "yes". Feedback would be really appreciated

[ben.dunn]

This seems to work for us as we were seeing the same issue when updating a pull request on Github

However it doesn’t seem to fetch the latest commit message, i.e. the commit message does not match the commit hash for the build

[viktorbenei]

@ben.dunn

However it doesn’t seem to fetch the latest commit message, i.e. the commit message does not match the commit hash for the build

What’s the commit message?

Keep in mind that pull request builds don’t build the commit directly. Pull Request builds are building the PR’s commit merged on the target, to simulate the code state after you click “merge” on the PR.

[viktorbenei]

The new, V4 Git Clone step was just released, which now includes the “manual merge” mode on “yes” by default, so this doesn’t have to be changed manually anymore.

Git Clone Repository v4.0.1

We released a new version (4.0.1) of Git Clone Repository step. Changes: Step revision Breaking change: manual_merge default to yes

The V4 of the step includes pretty much a 100% revision of the step’s code. We tried to keep everything backwards compatible (all inputs etc), with the exception of the “manual merge” mode which is enabled by default now. There’s still an option to turn it off and use the old GitHub specific “merge strategy” for PRs, but that should be avoided due to the related recent GitHub changes (more info in my comment above Invalid commit checked built on bitrise.io - #2 by viktorbenei ).

We tried our best to cover every edge case and keep the V4 version of the step backwards compatible, but if you’d have any issues please let us know!

Happy Building!

[Jolanda]

It seems that this issue still occurs when you use a PR from a private repository, as a manual merge is not possible in that scenario. Do you have a reference to some issue report at Github about this lagging behind?

[viktorbenei]

Indeed PRs into private repos from private forks still use the old method. We scheduled an update for this, should be out next week.

Note: this of course does not affect PRs from the same repo, only affects GitHub PRs where we can’t directly access the fork, due to the fork being private and requires additional / different auth, in which case we still use the old, GitHub provided /merge branch.

Sorry for the inconvenience, we’ll try to push the update next week ASAP!

[anon389916]

In release 4.0.6 we updated the merging method for PRs from private repositories. The old method used the pull/x/merge branch provided by GitHub, which is sometimes lagged behind. In the updated version the step pulls the base branch and merges the pull/x/head branch into it. The pull/x/head branch is the latest version of the PR branch, so this way the merged code always be up-to-date.