How to surface git commit hash and message in Bitrise job?

Please see:

Am I missing something as to why the git commit hash and message are not being pushed to the Bitrise site?

It simply says:

Commit hash:
no commit hash specified
Commit message:
No commit message

In the build logs, I see the following:

Git Clone Configs:

  • CloneIntoDir: /Users/vagrant/git
  • RepositoryURL:
    Git Checkout Configs:
  • Commit:
  • Tag:
  • Branch: development
  • CloneDepth:
    Git Pull Request Configs:
  • PullRequestURI:
  • PullRequestID:
  • BranchDest:
  • PullRequestMergeBranch:
  • ResetRepository: No
    Bitrise Build Configs:
  • BuildURL:
  • BuildAPIToken: FqO3u78T3tELvlzKwoSk3Q

Git clone repository
=> git “init”
=> git “remote” “add” “origin” ""
=> git “fetch”
=> git “checkout” “development”
=> git “submodule” “update” “–init” "–recursive"
Exporting git logs
value: 004446a1f5ce7082e58df197d8e71ab83bd59859

value: Merge pull request #1123 from cliqueinc/uit-filterTests

value: [UI Tests] Filter Tests

value: juliancmg


value: GitHub


Please let me know if I can provide any more information.

You most likely started the build manually, without specifying the commit hash & message.

On you see the infos the build was started with. If you only provide the branch, then only the branch will be listed there, as all other infos are only available after the git clone (it might even be that you push new commits to the branch before the git clone would happen).

The best solution is to use Webhooks to automatically start the build, without any manual interaction; and the webhooks do include the commit message and commit (and that specific commit will be cloned, not just the tip of the branch). Related docs:

Got it. I was definitely manually kicking off some UI test jobs as they were failing since they are not being run on every commit yet. Thanks for the information @viktorbenei!

1 Like

Makes sense :slight_smile:

Just one note, mainly for future ref. - if you rebuild a build where commit message & commit hash are specified, then those will be presented on the rebuilt build / in the build infos of the rebuild too, and the build will build the same commit.

On the other hand, not specifying the commit hash can also be useful.
If you (re)build a build where the commit hash was not specified it’ll always build the tip of the branch - which can be useful in e.g. the case you described, or when you want to do a manual deploy with the current “master” for example.

1 Like