Yeah, that’s what I thought.
I’ve worked around this by triggering the API with specifically checking out the correct commit in the install
stage:
"request": {
"message": "(${TRAVIS_COMMIT:0:7}) $TRAVIS_COMMIT_MESSAGE",
"branch": "$TRAVIS_BRANCH",
"config": {
"merge_mode": "replace",
"language": "java",
"jdk": "openjdk12",
"install": "git checkout -f $TRAVIS_COMMIT",
"script": "./mybuild.sh",
"env": {
"global": [
"TRAVIS_COMMIT=$TRAVIS_COMMIT",
"TRAVIS_COMMIT_RANGE=$TRAVIS_COMMIT_RANGE",
"TRAVIS_COMMIT_MESSAGE=\\"$TRAVIS_COMMIT_MESSAGE\\"",
"TRAVIS_TAG=$TRAVIS_TAG",
"TRAVIS_BRANCH=$TRAVIS_BRANCH",
"TRAVIS_PULL_REQUEST=$TRAVIS_PULL_REQUEST",
"TRAVIS_PULL_REQUEST_BRANCH=$TRAVIS_PULL_REQUEST_BRANCH",
"TRAVIS_PULL_REQUEST_SHA=$TRAVIS_PULL_REQUEST_SHA",
"TRAVIS_PULL_REQUEST_SLUG=$TRAVIS_PULL_REQUEST_SLUG"
]
}
}
}
(I have sanitized the TRAVIS_COMMIT_MESSAGE for json consumption)
This is far from a perfect solution, but it kinda works.
Caveat: The git commit SHA shown in the Travis UI will always be the latest one, and that might not match the commit I checked out in the install
stage. That’s why I’ve added it to the message
.