.github/workflows: build master branch of RIOT, bump container version

[crasbe]

Contribution Description

In my opinion, the build test of the docker containers should always build the latest master branch of RIOT instead of the Release branch, as any changes to the RIOT repository (such as the ones made for #285), are not pulled in for the build test.

Furthermore, I would like to detach the version number of the Docker container from the RIOT release version. This would make it possible to pin the Docker container version in the Releases of RIOT and avoid having to update and backport them when an update in the Docker container happens.

This might require some additional logic in makefiles/docker.inc.mk, but I'll have to check that.

Related Issues

This closes #84.

[crasbe]

Before merging this, I would like some feedback from @maribu especially.

Also, some documentation about how the versioning works would be appropriate.

To be honest, the "release" mechanism isn't ideal either and that could use some optimization. In it's current form, the latest container and the container with the highest version number are always identical, however it would be better to have a dedicated release mechanism to keep the released container untouched. Perhaps by adding a VERSION file and if that is changed with respect to what's already released, a new release is published to the Docker library.

[AnnsAnns]

I don't fully understand 2026.08.01

[crasbe]

I don't fully understand 2026.08.01

My thought was that the riotdocker might have more minor releases than the RIOT mainline, but on the other hand probably not 😅

[maribu]

Sorry, I'm not really availabe for the next two weeks due to moving.

I'm not sure what the tag here does. It probably was kept in sync with RIOT releases. There might be some doc in the release manager "handbook".

It might not really be needed, though. We pin the compatible container by image hash in docker.inc.mk anyway. I haven't checked if untagged versions will get garbage collected, though; that would of concern. The possibility to bisect with BUILD_IM_DOCKER=1 without having to worry about an older RIOT version no longer compiling with a newer toolchain (because new diagnostics now catch bugs old GCC/clang didn't spot).

[crasbe]

So okay, the new procedure is essentially this: The version of the docker container has to be bumped after the release, so that the tag that the last RIOT release uses remains stable and is not "garbage collected".

In the past this worked by accident, but not necessarily by procedure. I've extended the documentation in the README and will try to take care of it for future releases.

[AnnsAnns]

might make sense to mention in the release guide

[crasbe]

might make sense to mention in the release guide

Yes, I might feature creep that into RIOT-OS/RIOT#22593