KOS is fundamentally an assembly based platform which is considerably different from a more typical build based platform. This distinction is critical because it impacts tooling, how build pipelines work, how releases are defined and even how software gets installed on a device. In order to better explain what an assembly based platform is, let’s start with a more typical build based platform.
Consider a typical yocto based Linux distribution. This provides a base operating system and on top of that we want to add a few custom native programs. These are typically integrated into the yocto build which checks out all the source code and builds everything from scratch, resulting in an image that can be installed on a device. Add to this some java programs, perhaps some data files and so on, and now you have a combination of builds of different components, all of which get pulled into that final image which is used for install. This is what we call a build based platform because every change ultimately requires building all the parts and then packaging them up together into an image or installable file of some sort.
KOS uses an assembly based model. A release does not consist of anything other than a manifest which lists references to all the pieces that make up the release, each piece being a KAB file. The manifest contains none of the actual software to be installed, only references. This is conceptually very similar to how docker works, where the actual resulting software stack is defined entirely as a set of references.
There are a number of implications of this approach, and many of them make things easier rather than more complex:
There is no need to rebuild components that have not changed from the previous release. It’s certainly ok to do so if it’s easier for other reasons, but it’s not technically required.
Build pipelines have no need to aggregate components, so they can tend to be much smaller and simpler, building just one or a handful of KABs per pipeline.
KOS Studio provides a KAB registry that tracks all available KAB metadata from internal build pipelines which allows any KOS Studio user to assemble and test an image using any existing build artifacts without the need to change build pipelines or even trigger a new build.
Using the KAB registry, KOS Studio knows where you store your KAB build artifacts and can automatically download them when needed, such as when installing them on a device for testing, or packaging up all the KABs for an actual production release.
KOS Studio can build a release manifest automatically, validating all required KABs in the process and even pulling in the correct architecture and board type variants of a KAB based on the target device.
While assembly based platforms require tracking more information about individual builds, KOS Studio handles all of this automatically and the net effect is typically a much simpler and quicker build process.