I have a step in a build workflow like so:
- slack@3.1.3:
title: Slack message on failure
is_always_run: true
run_if: .IsBuildFailed
inputs:
- channel: '#dev_mobile_platform'
- text: ""
- text_on_error: $PEAR_BUILD_FAILURE_MESSAGE
- webhook_url: $SLACK_WEBHOOK
Where $PEAR_BUILD_FAILURE_MESSAGE
is a build failure message generated by a previous step.
These builds are triggered via the Bitrise API from other builds on bitrise.io. When one of these results in a failure I see a message like this:
The same commit message is displayed every time there is a failure, regardless of which commit the build was actually built from. Worse yet, one of them shows a commit message from a COMPLETELY SEPARATE REPO which is very confusing.
I am actually passing a build message on these jobs as you can see here:
Here are my build parameters from this build:
{
"branch": "master",
"commit_message": "react-native-pear-login test triggered from upstream dependency 'react-native-pear-platform@9.0.1-next.2125'",
"commit_paths": null,
"environments": null,
"workflow_id": "test_edge"
}
The step seems to be pulling this message by default from the GIT_CLONE_COMMIT_MESSAGE_SUBJECT
and GIT_CLONE_COMMIT_MESSAGE_BODY
envvars.
So, it seems somehow that if the build was triggered manually, these envvars will not be set, even if commit_message
was supplied as a build parameter.
I can understand them being null, but having them populated with stale and incorrect data (which in some cases was from another repo entirely) is a bit troubling and breaks my expectations about how the sandboxed build VM is supposed to work.