The container should have versioning and releases

[jcarrano]

RIOT has versioning and regular releases. RIOT depends on this image as it is part of the build system.

Both RIOT and the image are thoroughly tested on each release (of RIOT) so that we know RIOT builds with the particular version of riotdocker that was active when the release was done.

The problem is: that image is not being saved anywhere. In other words, the Docker integration in RIOT always uses latest, and there is only latest because riotdocker does not have versions.

What this means is:

• Past releases of RIOT may be broken as they use "latest" and latest keeps on being changed.
• The latest release of RIOT may well be broken the day after it is relased, just by updating the image (or even by just rebuilding it, since it does a apt-get update && apt-get -y dist-upgrade) And because the release is already out, it is not being tested.

What I propose:

• Have a version of riotdocker for each release of RIOT. These should not get changed except to fix bugs (though nobody is reporting bugs against a release.)
• Change RIOT to use the release-specific image.
• Have a master/latest image, than can build the master RIOT.
• Have a CI release, that can also build the master riot. Merge master into CI anb deploy once in a while.

Steps:

• Create branch
• Update build rules in Docker Hub.
• Come up with a testing/deployment procedure
• Update the docker integration in RIOT.

[jnohlgard]

I agree with your concerns, it is bad that we are only using the latest tag. Providing one tag per RIOT release sounds like a future-proof solution which should allow still building old releases for bug fix testing etc. A tag for the rolling development is also useful when working on development of the RIOT master branch.

[jcarrano]

I created a new branch '2019.01-branch' at the point where we were at the last RIOT release (which is also the point at which we are now.)

What I need now is someone with access to our Docker Hub account configures the build so that the riot/riotbuild:2019.01-branch exists and builds from the new branch.

Next step is to update RIOT itself to use the image.

[jcarrano]

Does anybody care? I insist: the way we are handling the docker image now means we can break the current release at any point, and previous releases are certainly broken. I do not think this is acceptable,

[miri64]

Shall we start with this now, that 2019.04 is out?

[miri64]

Does anybody care? I insist: the way we are handling the docker image now means we can break the current release at any point, and previous releases are certainly broken. I do not think this is acceptable,

I care and agree, so please go ahead!

[jcarrano]

@gebart Could you give me access to the container at DockerHub?

[dberliner]

The lack of versioning has caused an issue with my workflow. I am trying to rereun a build from a year ago that includes some now deprecated code. The environment created last year compiled that code just fine, but todays environment throws an error. This would be a non-issue if I could just specify a tag to pull from last year.

I ask that this issue be given some more attention. I think it is integral to the problem that Docker images are trying to solve in the first place.

[miri64]

@kaspar030 @fjmolinas AFAIK the deployment process is mostly automated. Is there a reason why we can't version the docker images?

[fjmolinas]

@kaspar030 @fjmolinas AFAIK the deployment process is mostly automated. Is there a reason why we can't version the docker images?

Nothing, just add that in #136, see 0141a45, here is my test branch https://hub.docker.com/repository/docker/fjmolinas/riotbuild images tagged with a release version.