RIOT-OS
build.yml: update links to RIOT examples
As follow-up of https://github.com/RIOT-OS/RIOT/pull/21135 and https://github.com/RIOT-OS/RIOT/pull/21221
(Note that the workflow is expected to fail until the latter PR is merged)
Switched to a new branch '2024.01-branch'
branch '2024.01-branch' set up to track 'origin/2024.01-branch'.
ah, it checks out ~~the latest~~ some old release :thinking: does that make sense?
https://github.com/RIOT-OS/riotdocker/blob/7b70ae29add1ed7709767704d4b862a949b2b9e1/.github/workflows/build.yml#L39-L40
That usually gets updated manually, so indeed this PR will need to wait until we next update things after a release is out with the changed locations.
In the meantime, we can start getting there with https://github.com/RIOT-OS/riotdocker/pull/257
That usually gets updated manually, so indeed this PR will need to wait until we next update things after a release is out with the changed locations.
Here we are after the next release, added a second commit that bumps the RIOT_BRANCH.
I think this should update the tag too. (AIU, VERSION_TAG is what gets set on the riotdocker image -- ie. it needs to be there before the release already.)
Do you have the time to get this ship-shape so that I can rebase #261 onto it?
I think this should update the tag too. (AIU, VERSION_TAG is what gets set on the riotdocker image -- ie. it needs to be there before the release already.)
Hu, can you elaborate? I don't understand.
I think this should update the tag too. (AIU, VERSION_TAG is what gets set on the riotdocker image -- ie. it needs to be there before the release already.)
The bumps of RIOT_BRANCH and VERSION_TAG are, as I understand the process, always done in pairs.
The branch points to the last release, that's what is being tested. (Or is that the branch after that release forked off? Either way, the latest date branch).
The VERSION_TAG is not a tag in the sense of a git tag (that is generally immutable), but a docker tag that can be updated regularly. It indicates the version of RIOT for which this image is being built (ie. we now stop updating the 2025.04 image, we really should have done that already when that was released, but everything we build now should be tragged 'latest' and also '2025.07'.
The branch points to the last release, that's what is being tested. (Or is that the branch after that release forked off? Either way, the latest date branch).
It contains the last release tag and any further backported PRs that did not warrant a new point release.
The VERSION_TAG is not a tag in the sense of a git tag (that is generally immutable), but a docker tag that can be updated regularly. It indicates the version of RIOT for which this image is being built (ie. we now stop updating the 2025.04 image, we really should have done that already when that was released, but everything we build now should be tragged 'latest' and also '2025.07'.
Ah, I thought this was also referring to git. Then I see what you mean. The question is how useful such a docker tag is if it is never properly updated as part of the release: https://hub.docker.com/r/riot/riotbuild/tags
Should we maybe just get rid of it and just push to latest? RIOT now pins the docker version anyways independent of the release version.
No, the tag is still useful: Anyone who uses, say, RIOT 2023.07 can still get the 2023.07 docker container. While we usually take some time to do the bumping update here, that docker container will "just" be from some point in time between 2023.07 and 2023.10 (maybe 2024.1 if nothing big happened), but it's still a container that they can expect to be useful -- whereas if we just did latest, the old containers would be lost, and rather sooner than later there wouldn't be an easy way left to run the build system of old versions.
whereas if we just did
latest, the old containers would be lost, and rather sooner than later there wouldn't be an easy way left to run the build system of old versions.
Are they lost as in deleted from dockerhub, or just not easily accessible via image tags? Since any RIOT git revision for some time now explicitly pins the docker image to a certain image hash, we still have the build system available that was used in the CI, even on a more fine-grained scale than just "somewhere between releases".
Hum, seems like we need to backport https://github.com/RIOT-OS/RIOT/pull/21531, too (otherwise static tests will also fail on the release-branch I guess).
Yes, sorry. We also need that backport to be able to backport other PRs, as Murdock will use the same image for both backports and PRs to master. See https://github.com/RIOT-OS/RIOT/pull/21541
Just force-pushed the changes together, if CI is still green this should be ready to go.