Bit-baking with soda

This time I want to write something about an issue everybody maintaining a git repo might faced already - CI. In theory every push and every pull request should have been build with all supported layer-versions... well in theory. The issue If you have a local setup it's sometimes hard to switch layer-version - I agree the usage of repo  is highly recommended here, as it simplifies such work heavily. Nevertheless you might need multiple work spaces, which all need a lot of disk space. Roughly calculated you can expect ~50GB of data per architecture/distro-combination without the usage of " rm_work "-bbclass, round about 15GB if you're using it. So if you decided to support >3 layer versions of YOCTO, it's a lot of space blocked for a lot of redundant data. Not to mention that you need to build everything now and then to get results, if your code is still working or not. Solution: CI This is where you pick a CI provider - Jenkins immediately comes in

What it this about? I know, I know strange title for a blog post. When dealing with YOCTO you mostly spend time at a single recipe while developing (at least I do), so everything is right at one place - not a big deal. But an image consists of multiple of those packages and they should all play well together. Sometimes there are "global" component (like web server) which are used by many components at the same time. And here comes the issue. I had the pleasure of putting a nginx based web server together which was configured by a bunch of configuration files, which were produced by a lot of different packages. In theory this works quite well, as you simply just adjust where it's needed, everything else should be done by bitbake - well in theory... The issue was that in a single configuration fragment a typo existed, which didn't get noticed until the whole construction was started on the target device - I personally think this is way too late. There has t