EXTENSIONS

Eight workflows composing @dataverket/ko, @dataverket/cosign, @dataverket/flux and @dataverket/crane. `@dataverket/ko-signed-images`: a signed build, every command of one Go module built into an image by ko and pushed, every image signed by digest with cosign using a key held in a vault, every signature verified. `@dataverket/ko-signed-manifests`: signed manifests, ko resolve renders them with every ko:// image built, pushed and pinned by digest, each image is signed, the rendered manifests are attested onto it as a custom predicate, and both are verified. `@dataverket/verified-manifests`: every image a rendered manifest file names verified against a public key, read-only, a gate before a deploy. `@dataverket/signed-release`: a directory of rendered manifests pushed as one OCI artifact with flux push artifact, tagged with the commit, with a release.json listing every image by digest from this run's resolution record, the artifact signed by digest, the rendered manifests attested onto it, both verified. `@dataverket/verify-release`: the gate, read-only, the artifact's tag pinned to its digest with crane, its signature and custom attestation verified against a public key, release.json read out of its layer, every image it lists verified by digest. `@dataverket/pinned-base-image`: an upstream base image resolved to its digest with crane, held in quarantine until that digest has been the tag's for minimumAgeDays, verified keyless against the publisher's identity, copied into our registry by digest, signed with our key and verified, the mirror record then feeding ko-signed-images through baseImageFrom. `@dataverket/promote-release`: verify-release as a nested workflow, then the channel tag such as current pointed at the verified digest with crane tag and read back, the digest it held before recorded for a rollback. `@dataverket/mirror-release-images`: verify-release, then every image the release lists copied by digest into another registry with its sha256-<hex> signature tag, and verified there. Each run fails unless all of it happened for all of the images.

A container registry driven through crane, the registry client of go-containerregistry: tags resolved to digests, images and indexes described, images mirrored in by digest, digests given tags, and a file read out of an artifact's layer, every outcome a swamp record.

A throwaway Salmon for end-to-end tests of anything that takes Salmon's tokens: database validators, message brokers, services.

One named kind (Kubernetes in Docker) cluster for swamp, created on demand for end-to-end tests.

One workflow, `@dataverket/mirror-forgejo-to-github`, that mirrors every repository of a Forgejo org to a GitHub org and keeps it that way.

One workflow, `@dataverket/platform-health`, that checks the forges, S3 gateways and HTTP endpoints a repository names and fails when one of them is down.

One HTTP or HTTPS endpoint, asked whether it answers, as swamp data.

Go programs built into container images by ko, https://ko.build: no Dockerfile, no container daemon, one image per main package, pushed to a registry, loaded into the local daemon, or written to a tarball.

Flux for swamp: HelmReleases, Kustomizations and sources as three model types, read with kubectl and driven with the flux CLI; and a directory pushed as an OCI artifact for an OCIRepository to pull.

Container images signed and verified with cosign, https://github.com/sigstore/cosign, signed with a key, with or without a transparency log, verified against that key or keyless against the identity in a Sigstore certificate.

SOPS + age vault for swamp: one encrypted file per secret.

Zitadel for swamp, over its API: seven model types, one per resource, with the whole life cycle of each.

A versitygw S3 gateway for swamp, read over its admin API and its S3 API. Read-only.

Talos Linux machines for swamp, through `talosctl`, with or without Omni.

OpenStack for swamp, through the official `openstack` CLI.

Sidero Omni for swamp, through `omnictl`. Two model types, two roles.

GitHub repositories, releases, pull requests and repository settings for swamp, over the REST API. One model type, `@dataverket/github`.

Forgejo (or Gitea) administration for swamp over the /api/v1 REST API with a scoped access token, in one model type, `@dataverket/forgejo`.

Two methods for `@smith/docker-compose` that end-to-end setups need.