search

teameh / bitrise-step-bitbucket-server-post-build-status

MIT License
3 stars 8 forks source link

$GIT_CLONE_COMMIT_HASH cant be trusted as post build status target #2

Closed RtgrV closed 4 years ago

RtgrV commented 4 years ago

When using the Git Clone repository plugin while enabling the config Limit fetching to the specified number of commits, returns output for $GIT_CLONE_COMMIT_HASH on a commit which was never pushed. At least from what I see, you are on HEAD.

When sending the status to Bitbucket, it succeeds but doesn't do anything. As there is no PR bind to this commit.

I think a solution would be to use the environment variable $BITRISE_GIT_COMMIT instead.

RtgrV commented 4 years ago

It seems I made the wrong assumption, Limit fetching to the specified number of commits doesn't cause this issue. But I do see that the Git Clone repository plugin creates a new commit based on a merge with the target branch.

I'm wondering if by changing the commit environment variable, this issue gets fixed.

RtgrV commented 4 years ago

I figured in version 0.0.8 I was able to override the valueGit commit hash with $BITRISE_GIT_COMMIT. Which worked for our implementation. In 0.0.9 this is blocked. Can it be reverted?

adelavina commented 4 years ago

Same problem here. Reverting to 0.0.8 to correct it; two scenarios happen:

-Merge goes straight to HEAD by fast-forwarding ---> No new commit is generated. -Merge actually merges files ---> New local commit is generated, and thats the one commit hash which doesn't make sense on the bitbucket server; $BITRISE_GIT_COMMIT does.

teameh commented 4 years ago

Yes, I thik this could be reverted. I'll try to fix this this week

teameh commented 4 years ago

Fixed in https://github.com/bitrise-io/bitrise-steplib/pull/2449