Make the git command available for pre-build steps

[wetzeld]

We want to automatically generate version information during our builds. In order for this to work seamlessly both for CI-builds as well as local dev builds, we aim to do this using a pre-build step in the Cube IDE. During this step we need the git command, so we would like have it available in the CI action as well.

[xanderhendriks]

There is already something implemented for versioning as shown in the sample application: xanderhendriks/stm32-sample-application I would be happy to merge in your change, but I would love to understand how this versioning will work. Do you have a link which explains what you are trying to do?

[wetzeld]

I don't have a link with a complete example, but basically, you would define a pre-build step that executes a shell script that generates a version info header file.

A minimal example of this shell script could look like this:

#!/bin/bash
DESCRIBE=`git describe --tags --always`
cat <<EOF > Core/Inc/version.h
#ifndef VERSION_H_
#define VERSION_H_

#define FIRMWARE_VERSION     "${DESCRIBE}"

#endif /* VERSION_H_ */
EOF

The script that generates this version.h file will then be executed every time the firmware is built, regardless of during a CI build or as a local build by a developer. As the Windows Cube IDE bundles and executes the build inside busybox, this script will work for Linux and Windows users, as long as you only use commands supported by busybox.

From how I understand you include version information in your example, the main difference of this solution is that it will also work for non-CI builds out of the box, as long as the developer has git installed and available in the path. I consider that a big advantage, as it ensures all firmware builds will have some sort of sensible version number or revision information embedded.

Of course, the actual script you want to use will probably be a bit more complicated, to e.g.

• parse the git describe output and split it up into up into major, minor version, etc.
• check whether the working copy contains any unstaged/uncommitted changes and mark the build as dirty if true
• differentiate local vs CI builds
• ...

Also, the fact that the version.h will be generated every time the build performed, could also be an issue for some, as it causes at least parts of the firmware to be recompiled and linked. That could be mitigated by only replacing/writing the version file if "relevant" changes have occurred.

[xanderhendriks]

I don't see how you would avoid having to rebuild after changing the version. Unless you would allow for the version to be written to the binary afterwards, but then you also run the risk that a binary ends up with the wrong version info.

I never want to get any binaries build on a devs computer to end up in the field. Hence the 0.0.0-debugbuild for the version. Branch builds can be selected to be deployed in the field and end up having 0.0.0-<10 character githash> And only when merging a PR to master the release number is incremented, the code is tagged and the build is created with a version number m.m.b-<10 character githash>

It has worked well for us. But happy to merge this change to allow for a different method.

[xanderhendriks]

Created tag v12.1