Artifacts, Instances and Sources
Previous concepts have discussed how the KOS operating system is defined as a collection of KAB files containing everything from the Linux kernel to developer applications and data. Some of these KABs are published by the KOS team while others are built by organizations using standard build pipelines. A collection of these KABs are gather together into a manifest KAB and that is used to install a release on a device. While all pretty straight forward conceptually, it does not answer the question of where are all the KABs, how do we know what’s available and how to we fetch them, so we can actually install them? That’s what we’re going to cover here.
Before getting into the details, there are two commonly used terms that we need to define in a very specific way when talking about KOS:
-
artifact: While sometimes the term artifact is used to describe a particular file, in KOS terminology an artifact represents a concept, not a file. For example, a device may need an admin ui. It has not been written yet, there is no code, no KAB or anything else other than the concept of the admin ui itself. It is possible to talk about it, put it in a schedule, and even plan for it even though it does not exist yet.
-
instance: An instance in KOS is a KAB file that is a particular version of an artifact. When you write the admin ui code and build a KAB, that is an instance. There can be many instances of an artifact. For example, there may be version 1.0, 1.1 and so on. Even for a given version there may be multiple instances. For example there may be an x86 and arm variant of version 1.0 of a given artifact.
As you can imagine, for any given project there may be many artifacts, each with many instances that increase over time as more and more versions are created during the life of the project.
KOS Studio uses the concept of artifacts and instances to build a catalog of all available instances, so they can be used to define a device manifest. KOS Studio provides a publish tool that can be utilized in your build process to notify KOS Studio when a new instance has been built. This allows KOS Studio to track the meta data about the KAB, such as the associated artifact type, version, variant, size, hash and location of the KAB. This data is automatically synchronized to all users in your organization, allowing KOS Studio to use the latest build artifacts when installing on a device.
Let’s examine how this works in more detail as a series of steps that would occur in a real project:
-
Build a new component: As part of the architecture and design process, identify a component that needs to exist in your solution, such as an admin ui. Start building the component, and build a local KAB for initial testing.
-
Create artifact in KOS Studio: Once the component reaches a point where it’s ready to be shared, such as for inclusion in a build for the QA team, use KOS Studio to define the new artifact with a name of admin ui.
-
Build automation with publish: Setup an automated build process for your new component and at the end of the build, copy the KAB to a location everyone in your organization can access. Use publishTool to notify KOS Studio that a new instance of admin ui, with the specified version and location, is now available. If this is a snapshot release, it will publish over top of the previous record which pointed to the previous KAB.
-
Add the instance to a manifest section: Using KOS Studio, select the manifest section to contain the KAB and select the particular version of the artifact you want to include.
-
Click the run button: Anyone in the organization that runs the manifest will now automatically have the latest version of the KAB installed onto their device or simulator. KOS Studio will use the location data in the catalog to download the latest KAB and install it automatically.
Since KOS Studio tracks all versions that have been published, if a developer wants to test with the previous version, they simply select the older version and hit run. KOS even has support for virtual versions which contain wildcards, allowing manifests to automatically include the newest version, or the latest version in a series such as 1.x.
KOS Studio also support creating live child manifests, allowing developers to quickly create a child of an existing manifest, swap out several parts and test it locally without disrupting teams sharing the parent manifest. This allows for very rapid testing as there is no need to rebuild old versions or trigger a custom build just to swap a few components.
The last part understanding artifacts and instances is artifact sources. Consider the case where your build server copies KABs to an AWS blob store. Over time many artifact instances are added to the catalog with references to this AWS blob store. Your organization then switches from Amazon to Microsoft so there is now a new Azure blob store for KABs and the old AWS blob store is shut down. The directory now contains many artifact instances that no longer work as the KABs were lost when the blob store was shut down. To account for this, KOS Studio has a concept of an artifact store and all instances are published relative to the store. In the example above there would be an AWS store that all KABS are published against and then a new Azure store when switching over. Once the Amazon account is closed, the AWS store in KOS Studio is deleted and all the associated instances will be removed from the catalog, avoiding dead links in the catalog.
