Docker images for running STM32Cube MX + build tools in CI/headless for automated builds

[Erlkoenig]

Hi,

there has been some interest in using STM32CubeMX code generation and also the Cube build tools (CMake, GCC, Ninja) in a headless mode, particularly for CI and typically via a Docker image, e.g. 1, 2, 3, 4. There are several benefits of being able to build STM32 projects automatically via CI, including specifically the code generation by STM32CubeMX, and to achieve this by using a Docker image:

• The CI setup acts as a "single source of truth" for the build process that defines the exact setup of tools needed, in contrast to some "random" collection of tools that happens to be installed on an individual developer's PC
• Therefore the CI also defines if a project's state or e.g. merge request is compilable; if it doesn't build on the CI, don't accept the change. No more "works on my machine" (at least regarding the build process)
• If the CI-based build is performed through Docker, the Docker image (and its Dockerfile) act as a documentation of the exact tools and versions used for compilation
• The CI can also be coupled with automated tests (particularly unit tests) run in a simulator or even HIL setup
• The compiled firmware images could be directly pushed from CI to some OTA update server (through manual confirmation), which establishes a clear update process that automatically documents which version was pushed when and prevents mixing up files manually
• Docker images can be archived to make sure the project can be modified & compiled again much later
• The code generation process by STM32CubeMX can accidentally overwrite code, e.g. when the user modified code outside the "user code" sections. Automatically running the code generation step on every commit in the CI and checking for modifications afterwards (using e.g. "git ls-files") can easily find such errors. This makes sure checked-in code is always in a "clean" state ready for fresh work with STM32CubeMX.
• When the code generation process is easily reproducible, generated files (i.e. the "Drivers", "Middlewares", "Utilities", "cmake"... directories) don't need to be checked in to version control (can be added to ".gitignore"). This de-clutters the commit history and results in compact "clean" projects.
• Projects that consist of many individual STM32 firmware applications which might be compiled in several different build configurations (e.g. Debug, Release, ReleaseWithLog, ...) can take a significant time to build. Automatically building on a powerful CI server makes sure any code change works with all dependent application projects in all configurations without slowing down the developer's PC.
• Docker images can also be easily installed on a developer PC, to allow quickly setting up the toolchain which is then also consistent with the CI's tools.
• AI coding agents can build and test their generated code through the CI build pipeline for immediate feedback.

Unfortunately, building a Docker image for running STM32CubeMX is not very straightforward. The application has various dependencies, requires a (virtual) X server, by default lengthily downloads updates and has a complicated CLI that requires writing command scripts. The firmware packages need to be installed individually, require a lot of disk space, and the patch-versions of the offline zip packages in addition need the correct release version installed. Manually building such a docker image for every STM32CubeMX/firmware package update is very time-consuming.

Building a Docker image for the build tools (compiler etc.) however is comparatively simple. For VS Code-based projects, it's desirable to use the cube-wrapper (part of the STM32Cube for VS Code extension) to install & call the build-tools automatically; this ensures the Docker image uses the exact same versions of those tools as a regular installation of STM32Cube for VS Code does.

Therefore I've spent quite some work on automatically building two Docker images for STM32CubeMX and the build tools, respectively. I've managed to automate the process such that itself can run in a CI environment and automatically uses the most recent versions of the various software packages - allowing me to keep the images up-to-date with minimal effort.

I would like to share these Docker images with the community, probably through the GitHub Container Registry. This would allow anyone to easily build their STM32 applications in a CI setup, particularly also managed cloud-based CI services such as GitHub Actions or the GitLab.com-hosted CI, by a few simple commands in the respective CI configuration file.

To my understanding, the licenses of the software packages by ST contained in those Docker images (STM32CubeMX main application, STM32Cube_FW_xx Firmware packages, cube-wrapper) allow redistribution in binary form, except for the "STM32_Audio", "Sigfox" and "ThreadX" sub-packages. I excluded these last three packages from my Docker image.

I would like to ask if there would be any objections by ST to me publishing these Docker images containing ST software. Of course I'd reproduce ST's copyright/license notice in the docker image description, but since the images are meant to run unattended I obviously can't display an interactive SLA form. For transparency, I'd also publish the Dockerfiles that necessarily list, download & install these software packages by ST in an unattended way avoiding repeated license confirmation dialogs.

Thanks for reading and the community support!

[Ghofrane GSOURI]

Hello @Erlkoenig 

I'm currently checking your request. I will get back to you asap.

THX

Ghofrane

[Ghofrane GSOURI]

Hello @Erlkoenig 

Your request has been escalated to our development team under the internal ticket ID 224939.
I will keep you informed of any updates.

THX

Ghofrane 

[Erlkoenig]

Hi Ghofrane,

thank you very much, I'll be waiting for your feedback before publishing the software.

Best regards,

Niklas Gürtler