Skip to main content

​
Project

A Project is software that provides some functionality. The term “project” was chosen to align with a similar deps.dev concept. Each Project has a ProjectType. Valid ProjectTypes include:
  • platform: The Project represents a software platform, such as the Cloud Native Project itself.
  • addon: The Project represents a Cloud Native Project, which is defined as some software that extends the functionality of the Platform it is running on.
  • application-service: The Project represents application code that provides essential services to the rest of the application stack.
  • control-plane-provider: The Project represents a control plane service, such as GKE, EKS, or NKP.
  • application: The Project represents customer-specific or internal code.
Important: A Project is not the packaging of that software. Packaging of Projects (e.g. Helm, Kustomize, etc.) is described by the Package model–see below. Chkk collects a variety of raw information about hundreds of Projects, including:
  • Versioning scheme and release cadence
  • Licensing and support models
  • Source code locations
  • Releases and release artifacts
  • Components and images
  • Dependencies
  • Bugs, issues and risk assessments
  • Changelogs, upgrade considerations, and migration guides
  • Related packages–Helm charts, Kustomize Overlay Directories, etc.
  • Version compatibility matrices
  • Deprecation and end-of-life schedules
  • Service health and readiness checks

​
Project Component

A Project Component is a separate binary, daemon, or subsystem of a Project. Chkk’s Knowledge Graph stores a wealth of information about the component breakdown of a Project. We track changes to a Project’s component breakdown over time, allowing us to provide highly-contextual answers to questions like “At what version of ArgoCD was the ApplicationSet controller bundled with the ArgoCD project as a core component?” (hint: the answer is ArgoCD 2.3). This gives Chkk’s Knowledge Graph time-machine superpowers!

​
Project Release and Release Series

A Project may have one or more Project Releases. A Project Release is the versioned publication of a Project and typically has one or more release artifacts tagged with the Project Release’s version. A Project Release is always associated with a single Project Release Series. The Project Release Series’ version will depend on the versioning scheme the Project uses. For example, if a Project uses Semantic Versioning, the Project Release Series will be the major and minor version number.

​
Change

A Project Release can have many Changes. A Change describes a change that was made to some code, configuration default or configuration structure. Changes are typically listed in changelogs or release note collections. Changes can add new functionality, remove functionality, and potentially break customer environments. A Change can have many Change Enrichments. A Change Enrichment is any refinement or modification made to the original content of the Change record. AI agents enrich a Change record, for example, by adding classification labels, researching the accuracy of a release note, and rewriting it using additional context (e.g. GitHub Issues / PRs).

​
Package

A Package is a named bundle of software that is bundled (and identified) in the format of a specific PackageSystem. The term “package” was chosen to align with an identical deps.dev concept. A Package has a Package System which indicates the format of the Package. Chkk supports two package systems:
  • helm: Helm Charts
  • kube: Raw manifests, including Kustomize overlays
Note: Helm is both a Package System and a Deployment System. The Helm Chart is a Package whereas the helm install CLI command is the Deployment System.

​
Package Component

A Package has zero or more Package Components. For Packages using the helm or kube Package System, these Package Components represent a Resource (Deployment, DaemonSet or StatefulSet) that is installed by the Package. Package Components include one or more Project Components. For Packages using the helm or kube PackageSystem, these Project Components represent a Docker Image that is in the spec.templates.spec.containers field of the Package Component’s Resource definition. Thus, the Package itself is associated with one or more Projects via these Project Component -> Package Component -> Package relationships. Like Project Components, Chkk tracks changes to the composition of a Package and its configuration over time, giving us an ability to view the evolution of a Package.

​
Service Health & Readiness Checks

Service Health & Readiness Checks are diagnostic entities that validate project health through validation relationships before, during, and after upgrades. These checks are curated for specific project versions and deployment patterns, providing automated validation of upgrade success and system stability.