CIRRUS_BASE_SHA unexpected value in PRs

[cevich]

When working on a PR especially in CI, it's often required to check/examine/test all changes since the PR's working-branch was created from the upstream branch. One way to do this is using the command git merge-base $CIRRUS_BASE_BRANCH HEAD. According to the documentation for $CIRRUS_BASE_SHA, it seems they should be equivalent:

"Base SHA if current build was triggered by a PR"

Astonishingly, this is not the case. Instead, $CIRRUS_BASE_SHA will always track the current $CIRRUS_BASE_BRANCH HEAD, making $CIRRUS_BASE_SHA all but useless in a PR, once the branch moves.

Expected Behavior

Given the example situation:

A---B---C---D---E    <--- HEAD on $CIRRUS_BASE_BRANCH
         \
          X---Y---Z (PR)

I would expect $CIRRUS_BASE_SHA to always point at C no matter what. Even after commit D and then E are added.

Real Behavior

Given the same example situation:

A---B---C---D---E    <--- HEAD on $CIRRUS_BASE_BRANCH
         \
          X---Y---Z (PR)

It appears that $CIRRUS_BASE_SHA will point at D then E as they're added. Since the PR branch won't "know" about new commits on $CIRRUS_BASE_BRANCH, any git commands based on $CIRRUS_BASE_SHA will fail.

Related Info

This is a (tick one of the following):

• Website issue
  • Link to page:
• Task issue
  • OS: All
  • Task name: Any
  • Script/cache name (if applies): e.g. git log ${CIRRUS_BASE_SHA}..HEAD can break.

Mitigation

Though it would be nice if the behavior could be fixed, I can understand hesitation to not break anyone relying on this buggy behavior. In that case, I think the documentation should be updated so it's much more specific. Something like:

The current $CIRRUS_BASE_BRANCH commit SHA if current build was triggered by a PR. Note, this value will change as new commits are added. If instead the working-branch (used for the PR) common ancestor is desired, the command git merge-base $CIRRUS_BASE_BRANCH HEAD may be used.