poc/multiarch: proof of concept for multiarch builds, addind flashers and individual toolchain images #138
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As discussed recently this PR wants to show some things that we could do and leverage with build:
multi arch builds:
flashers
are built forarm64
amd64
andarmv7
. Toolchains are not built for all, ran into some issues and since this is a POC just went for those that were easy to handle.flasher images: I use [Tracking] makefiles/docker: add docker/% targets RIOT#12419 so commands of the type
docker/flash-only
since these images are meant to be light weight so do not contain compilation tools or toolchains. ~500Mb for openocd, definitely room for improvement for starters not using ubuntu as the base image, using multistage builds etc...individual toolchain images: easier to version and lighter
arm-none-eabi-gcc
lite image (won't be able to compile everything in RIOT) is ~700Mb and with all requirements to build ~1.4Gb. We can imagine versioning them according to the toolchain version as well as the current release.leverage multistage builds: in this case, it is done only for
arm-none-eabi-gcc
where only the binaries are copied.In this PR I added another base image
riotbuild-essentials
that want to gather all common build tools. A successful workflow can be seen at https://github.com/fjmolinas/riotdocker/actions/runs/622288134, once cache is hot the whole workflow is pretty fast ~10min, less for individual stages. Some of them could be decoupled, even split into workflows but currently, Github actions tools for workflow dependencies is pretty new and has quite heavy limitations, I would rather wait for it to mature before going there.Lastly, I'm currently hosting these images in my own registry if you want to try them out. I also have a simplified rebased version of RIOT-OS/RIOT#12419 in https://github.com/fjmolinas/RIOT/tree/dev/docker_targets which I'm mostly using ATM to flash on rpi3 with docker support over ssh. There a little more going into this but its also easy to setup.
So feedback wanted, is this worth pursuing? As you can see from the test workflow all the flashers part is quite independent and can be split out completely, in the past I had many more images https://github.com/fjmolinas/riotdocker/tree/flashtools_dockerfiles/flashers but I haven't tested them all and it was a while ago, but as you can see its pretty simple and easy to setup.
Splitting out the toolchains is a bit more of work (I for example had issues with picolibc and did not tackle that for now).
If this is worth pursuing IMO the first step is adding github actions workflows like #136, the flashers can be added, then some more base images like the
riotbuild-essentials
one and ariotbuild-test
or something like that. Then toolchains can be decoupled if wanted.