Overview

This repository builds and publishes the OKDP platform packages used to operate platform services with KuboCD.

It is packages-only: it owns the package definitions under packages/ and the CI that builds and publishes them as OCI artifacts. It does not own the deployment layer (releases, contexts, Flux/KuboCD bootstrap). Deployment lives in OKDP/okdp-sandbox, which consumes the packages published here.

KuboCD Concepts

• Package: a versioned OCI artifact that bundles a KuboCD application descriptor and one or more Helm charts. The manifests under packages/ define the packages published by this repository.

Packages are deployed through KuboCD Releases that reference layered Contexts. Those deployment resources are maintained in OKDP/okdp-sandbox, not here.

Structure

packages/
├── system/             # Infrastructure & system packages
│   ├── cert-manager/
│   ├── ingress-nginx/
│   ├── dns-server/
│   └── ...
└── services/           # Services
    ├── superset/
    ├── jupyterhub/
    ├── seaweedfs/
    └── ...
platform-packages-values.yaml   # OCI publish target (packageRepository), the source of truth used by CI

Key paths:

• packages/system: infrastructure and platform foundation packages.
• packages/services: data and application service packages.
• platform-packages-values.yaml: the OCI repository packages are published to.

Building Packages

The OCI repository packages are published to is defined once in platform-packages-values.yaml (packageRepository). Use the same value for local builds.

Basic Build Command

# Build a system package
kubocd package ./packages/system/cert-manager/cert-manager.yaml --ociRepoPrefix quay.io/okdp/platform-packages

# Build a service package
kubocd package ./packages/services/superset/superset.yaml --ociRepoPrefix quay.io/okdp/platform-packages

Custom OCI Repository

# Using a different OCI registry
kubocd package ./packages/system/cert-manager/cert-manager.yaml --ociRepoPrefix myregistry.io/my-org/packages

# Using a different prefix for packages
kubocd package ./packages/services/jupyterhub/jupyterhub.yaml --ociRepoPrefix harbor.company.com/okdp-prod

Examples

# Build all system packages
for pkg in packages/system/*/; do
  kubocd package "$pkg"*.yaml --ociRepoPrefix quay.io/okdp/platform-packages
done

# Build specific package
kubocd package ./packages/services/seaweedfs/seaweedfs.yaml --ociRepoPrefix quay.io/okdp/platform-packages

Build Output

Packages are pushed to: {ociRepoPrefix}/{package-name}:{tag}

Example: quay.io/okdp/platform-packages/superset:4.0.0-p02

GitHub CI and Publishing

The GitHub workflows share the reusable kubocd-package-template.yml workflow for both CI validation and publishing.

CI Workflow

ci.yml runs on pushes, pull requests, and manual dispatch. It:

• reads the OCI package prefix from platform-packages-values.yaml;
• builds every package manifest under packages/ that contains modules:;
• pushes CI test packages to the repository-scoped GitHub Container Registry path.

Building covers every package, so packaging errors are caught repo-wide. Deployment of the published packages (Flux/KuboCD bootstrap, contexts, releases) and its end-to-end validation live in OKDP/okdp-sandbox, not here.

The KuboCD package CI job is skipped for fork pull requests because GitHub intentionally gives those runs a read-only token, which cannot push to GHCR.

CI Registry

The ci workflow builds packages for CI validation and pushes them to the repository-scoped GitHub Container Registry path:

ghcr.io/okdp/platform-packages/platform-packages/{package-name}:{tag}

Release Publishing

Published release packages use the public repository from platform-packages-values.yaml:

quay.io/okdp/platform-packages/{package-name}:{tag}

publish.yml can be dispatched manually and publishes packages to Quay using REGISTRY_USERNAME and REGISTRY_ROBOT_TOKEN. publish-on-merge.yml triggers that publish workflow after a successful ci run on main, and release-please.yml triggers it when Release Please creates a new release after a merged pull request.