Zarf Init packages for Delivery

This repository releases three customized Zarf init packages. Each package is created for the upstream, registry1, and unicorn image flavors and for amd64 and arm64.

The package definitions import the upstream zarf-dev/zarf package sources at the Zarf version pinned by ZARF_SOURCE_VERSION. Shared values passthrough, health checks, and chart overrides live under components/.

Packages

Release	Package contents	Public OCI repository
init	injector, registry, agent	ghcr.io/defenseunicorns/delivery-zarf-init/init
init-agent-only	agent	ghcr.io/defenseunicorns/delivery-zarf-init/init-agent-only
init-gitea	injector, registry, agent, Gitea	ghcr.io/defenseunicorns/delivery-zarf-init/init-gitea

The unicorn packages publish beneath ghcr.io/defenseunicorns/packages/private/delivery-zarf-init/ instead.

Flavors

• upstream uses the upstream Zarf, Docker Registry, Socat, and Gitea images.
• registry1 uses Iron Bank images. Its arm64 images use explicit -arm64 tags.
• unicorn uses Defense Unicorns Chainguard FIPS images.

Each package has an independent entry in releaser.yaml. OCI tags use <zarf-version>-uds.<revision>-<flavor>, and GitHub release tags use <package>-<zarf-version>-uds.<revision>-<flavor>.

Consumers can verify against the exact package release tag:

keylessVerification:
  certificateIdentity: https://github.com/defenseunicorns/delivery-zarf-init/.github/workflows/release.yaml@refs/tags/init-v0.87.0-uds.0-upstream
  certificateOIDCIssuer: https://token.actions.githubusercontent.com

Deploy

zarf package deploy \
  oci://ghcr.io/defenseunicorns/delivery-zarf-init/init:v0.84.0-uds.1-upstream \
  --confirm

Repository layout

packages/init/             default init package and values
packages/init-agent-only/  agent-only package and values
packages/init-gitea/       Gitea package and values
components/zarf.yaml       flavor-specific component composition
components/common/         shared component definitions and chart values
flavors/                   flavor and architecture-specific image sources
releaser.yaml              independent uds-pk versions for all three packages
tasks/                     init-specific create, deploy, test, and publish helpers
tests/                     package-level fixtures
.zarf-src/                 generated upstream Zarf package sources (gitignored)

This is a pre-UDS bootstrap repository. UDS bundles and the UDS Package CR are intentionally inapplicable because the packages run before UDS Core exists. See docs/justifications.md.

Development

The public task names follow the UDS package template:

uds run                                      # create and install-test init/upstream
uds run create-dev-package                   # create without an SBOM
uds run test-install                         # create, deploy, and verify on a fresh cluster
uds run publish-package                      # create both arches, test when deployable, then publish
uds run test-zarf-values                     # validate schemas and passthrough
uds run pre-commit-all                       # run repository checks

Select another package or flavor with task variables:

uds run create-dev-package --set PACKAGE=init-agent-only --set FLAVOR=registry1
uds run create-dev-package --set PACKAGE=init-gitea --set FLAVOR=unicorn --set ARCH=arm64

The package names accepted by PACKAGE are init, init-agent-only, and init-gitea.

Building registry1 requires Iron Bank registry credentials. Building unicorn requires access to cgr.dev/defenseunicorns.com.

The vendoring task checks out only the upstream Zarf package definitions needed by these packages. All flavors use the shared ZARF_SOURCE_VERSION pin and validation requires their agent and release versions to match it. Move a stale .zarf-src checkout aside after changing the shared pin; the task does not switch source versions in place.

Test clusters use host ports 8080, 8443, and 6551 so they can coexist with a cluster using the conventional 80, 443, and 6550 ports. Override the K3D_*_PORT task variables as needed.

CI and release behavior

Pull requests:

• create all three packages for arm64 across all three flavors on trusted pull requests;
• install-test the registry-bearing packages across all three flavors on trusted pull requests;
• create every public upstream package and install-test its registry-bearing packages on forks and Dependabot; and
• validate Zarf values schemas and passthrough.

Install tests run only when a pull request changes package definitions, components, flavors, tests, tasks, or release metadata. Repository automation and documentation-only changes still create the packages and validate Zarf values, but skip the cluster end-to-end matrix.

Renovate creates two normal dependency groups: package dependencies and CI dependencies. Package dependencies include the charts, images, and release versions shipped in the Zarf packages; the CI group contains test fixtures, workflow actions, development tools, and repository automation. Renovate PRs stop before package tests until every flavor pin for a changed component is present at the same normalized version. Gitea chart-only updates also wait for the flavor images.

Zarf updates also advance every package and flavor in releaser.yaml. Registry, Socat, and Gitea updates do not create a package release by themselves; they ship with the next Zarf release unless an affected package receives an explicit -uds.N revision bump.

Pushes to main evaluate each package and flavor independently with package-scoped uds-pk and create each unreleased package-specific GitHub release tag. Each tag triggers a release job that creates both architectures, tests registry-bearing packages, keyless-signs and verifies them against the exact tag identity, and publishes both. A failed release can be retried from its tagged workflow.

Tag creation uses the uds-release GitHub Environment with the APP_CLIENT_ID variable and APP_PRIVATE_KEY secret for the protected release GitHub App. Repository rulesets must allow that App to create release tags. An App token is required because tags created with GITHUB_TOKEN do not trigger the tag-based release workflow.

The registry can be backed by S3-compatible object storage; see docs/s3-backed-registry.md.