Pull requests sometimes incorrectly determine they are not the branch tip

[jcantosz]

If running the shared library against PRs sometimes it will fail to determine that the PR is at the tip of its respective branch and it will thus fail to write to build versions. This occurs when the Jenkins merges the target branch in to the PR and thus gets a different commit hash (Ie. branch is no longer ahead of master)

It is not transparent to the user that this is happening and that is the cause of build versions not being updated. Building without this merge seems unwise since build results may differ before and after the merge.

There is not a clear way to fix this. We could disable the setting in Jenkins and make the library do the merge but that means that setup could be finicky. The merge should be detectable -- GIT_COMMIT will not match GIT_COMMIT_SHORT_HASH
Would love to hear other people's thoughts

Jenkins settings:

Behaviors:
  Discover pull requests from origin:
  Merging the pull request with the current branch target revision

jenkins.yaml:

common:
  eventRegistryKeys:
    - registryKey: commit/PR-(.*)
       registry: default

[jcantosz]

For the time being I am considering doing in my build.groovy

if ( env.GIT_COMMIT.take(12) != env.GIT_COMMIT ){
throw rebase your commit error message
}

[jcantosz]

Latest commits to dockhand fixed this, pulling these changes resolved my issue