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. The KOS team publishes some of these KABs while others are built by organizations using standard build pipelines. A collection of these KABs are gathered together into a manifest KAB and used to install a release on a device. While all pretty straightforward conceptually, it doesn’t answer the question of where all the KABs are; how do we know what’s available, and how do we fetch them to 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 hasn’t 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 doesn’t 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 project’s life.

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 metadata 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 the name of admin UI.
• Build automation with publish: Set up 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 be published over the 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 select the older version and hit run. KOS even supports virtual versions containing wildcards, allowing manifests to automatically include the newest or latest versions in a series such as 1.x.

KOS Studio also supports 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 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 of understanding artifacts and instances is artifact stores. Consider where your build server copies KABs to an AWS blob store. Over time, many artifact instances have been added to the catalog referencing 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 to avoid dead links in the catalog.