Thanks @kirk, we see many people have their own setup scripts but it would be nice to have something that is maintained and kept up to date with “the current recommended system”.
I think the first set would be to add a way to compare local system setup with that of riot/riotbuid.
Maybe a smart diff of make print-versions locally and in riot/riotdocker would give insight. But that would already require a working docker…
That’s what I was thinking. It wouldn’t be so hard to maintain a setup script for just docker and cloning RIOT. I was even thinking of adding the docker setup script and native setup script to the riot-docker repo and let actions do a check, thus ensuring the setup script matches what is in our dockerfile.
My concerns with that approach would be having a dependency on RIOT version as the print_versions.sh may change…
Hm, the docker container is based on ubuntu. Why don’t we wrap the “apt-get install” etc. into one script, check that into the riot repo, but use the same in the dockerfile? (just wget it from the github master tree link)
So the riotbuild docker would just call a setup script from the RIOT repo?
If so, how would that affect the docker versioning? I imagine we can pin specific commits to the docker image…
Also how would we test changes? We would need to indicate that a PR does require a docker image change or something. Though I do like the mono-repo approach, this way we would also know the state which RIOT is run vs keeping track of which docker version what used to test which commit of RIOT.
I like this, it is very DRY, but the wget either does not result in a cachable docker layer, or it results in a layer that never gets updated. Can we COPY it in, of the Dockerfile is in our repo?
I would assume that we’d pin a specific version, which then contains some commit hash in the URL. Any update of the file would require updating the Dockerfile line to a different RIOT branch commit hash.