I have a multi-container project that is being built and pushed to a fleet with balena push.
Locally, the git hash is 906aff205bba91ce2e1f7bd4f79ee8161556a2cb.
However, when I look at the hash in BalenaCloud for the release, it reports differently, here you can see the short hash is reported as 579fdcd:
There are no staged changes and the git history is clean.
What could cause these values to differ? Where does balena pull this information from?
Hello @cdalke-havoc thanks for your message and apologizes for the delay replying this.
I’m going to try to reproduce!
Let us know if we can help you with anything else!
Thanks, no problem. One other clue: our repositories use Git submodules, so maybe Balena is treating those differently than the local repo?
Hey @cdalke-havoc , when using balena push, the commit associated with your release is not the same as the git commit sha, but is a hash of the file contents that were uploaded to our build servers.
Using the legacy method of git push balena master would have resulted in the commits being aligned if I recall correctly, but the recommended balena push method does not inspect the git state when building.
So this is the expected behaviour!
Some users find that it is helpful to add a tag to releases including the git sha, for reference. If you have a CI pipeline using our deploy-to-balena action this is done automatically!
Interesting, thanks for the clarification. We started pushing a git_sha tag which works well.
It’s definitely useful to see that the contents of the release changed even when built from the same git commit.
That said, I think this is pretty misleading, I’d suspect most people read “Commit” or “Commit Hash” to mean “The current git hash on the repository that produced this build.” - but this answer is probably enough documentation if there’s any confusion.
Thanks!
