sean/pipelines-operator
Watch
1
0
Fork
You've already forked pipelines-operator
 0
Code Issues Pull requests 3 Projects Releases 58 Packages Wiki Activity
58 releases 58 tags
  • v0.1.18 f1c4b8ebb0

    v0.1.18 Stable

    gitea_admin released this 2026-07-06 17:52:46 +00:00 | 199 commits to main since this release

    Added

    • dockerfile-set taxonomy + renderer (builder-images) — a project that is ONE repo, MANY container
      images (images/<name>/{Dockerfile,VERSION}), per-image versioned. Renders ci + staging sensors (CI
      fans buildctl across the buildkit-alice fleet over only CHANGED images via pipeline-build-images;
      staging dispatches build=pipeline-build-images/test=pipeline-test-noop/promote=pipeline-promote-images
      through pipeline-staging), 2 branch-protections, provision (keyset build read), ci-artifacts. No
      build-script CM (nothing third-party compiles in-pod — trusted pipeline-build-images SA holds the
      push cred), no deploy (images are consumed by other pipelines). Parity-gated against the retired
      projects/builder-images/ overlay. Removes builder-images from the special-cased dir set.

    Included changes (v0.1.16 -> v0.1.18)

    • 16efa2831adc feat(render): dockerfile-set taxonomy for builder-images
    • f430e14b8b90 chore: re-drive the wedged v0.1.17 release (flaky promote main-ff transient; no code change)
    • 0beb43243394 fix(gitops-flux): staging sensor passes renderRoot + gitRepositoryName
    Downloads
  • v0.1.16 e56305692b

    v0.1.16 Stable

    gitea_admin released this 2026-07-06 14:58:26 +00:00 | 212 commits to main since this release

    Changed

    • gitops-flux now follows build→release→deploy (no longer special). The gitops-flux renderer
      (templates/gitops-flux/) restructures to the standard shape, identical to gitops-deploy except the
      deploy engine: the trunk sensor now runs pipeline-staging (validate-flux ▸ noop ▸ pipeline-promote-tag)
      — a SHIPPED clean x.y.z cuts a tag + ff's Forgejo main + Forgejo Release; a plain -dev land only
      validates — and a NEW <project>-deploy sensor fires on main-push → pipeline-deploy-flux
      (anchor=main). The CI filter gains the _devbump/ + release-cadence/ machinery exclusions (the
      taxonomy is now versioned). Pair with pipelines' pipeline-{validate-flux,deploy-flux} template edits
      and each repo's VERSION/CHANGELOG; the PipelineProject versionSource.kind flips none→file.
      Requires seanfarm/platform-seanfarm CRs on kind: file to actually release (a none CR stays
      validate-only). No new CR schema fields.

    Included changes (v0.1.15 -> v0.1.16)

    • d93ac82b6539 feat(render): gitops-flux follows build->release->deploy (no longer special)
    Downloads
  • v0.1.15 b38a4b2f16

    v0.1.15 Stable

    gitea_admin released this 2026-07-06 14:07:27 +00:00 | 217 commits to main since this release

    Added

    • gitops-flux + gitops-deploy renderers — the 6th and 7th (final) rendered taxonomies
      (internal/render/templates/gitops-{flux,deploy}/). Objects() now renders ALL 7 taxonomies.
      gitops-flux (seanfarm, platform-seanfarm): a versionless IaC repo — CI kustomize-validates
      spec.build.renderRoot via pipeline-validate-flux, the trunk push IS the deploy
      (pipeline-deploy-flux ff's the live codeberg source + waits Kustomization Ready@sha), and
      spec.deploy.flux.autoland renders an extra image-bumps autoland sensor (seanfarm); provision
      sets ENSURE_BRANCHES=trunk (one-shot codeberg seeds). gitops-deploy (pipelines self-host):
      versioned CI pipeline-validate + pipeline-staging tag release + a main-push deploy sensor
      (pipeline-deploy → ArgoCD Synced@sha + Healthy, dry-run gate + rollback). New CR fields:
      spec.build.renderRoot, spec.deploy.engine, spec.deploy.flux.{gitRepository,codebergRepo, syncTimeout,autoland} (spec.deploy.run.* already existed for argocd). No build-script CM.
      Parity-gated against the retired projects/{seanfarm,pipelines}/ dirs (incl. autoland/deploy sensors).

    Included changes (v0.1.14 -> v0.1.15)

    • f4d5aaf9044d feat(render): gitops-flux + gitops-deploy renderers (6th + 7th taxonomies — ALL rendered)
    Downloads
  • v0.1.14 c1caa2e836

    v0.1.14 Stable

    gitea_admin released this 2026-07-06 13:39:58 +00:00 | 222 commits to main since this release

    Added

    • server-package + desktop-package renderers — the 4th and 5th rendered taxonomies
      (internal/render/templates/{server,desktop}/). Objects() now renders both Zig packaging
      taxonomies: CI via pipeline-build/pipeline-build-desktop, staging via pipeline-staging with
      the pkg-install matrix + gpg-signed apt/dnf promote. New CR fields: spec.signing.{method,keyRef},
      spec.test.{debImages,rpmImages} (the RESOLVED install-matrix images, carried verbatim so a tester/
      base-image bump is a CR edit — zdns=amd64 base images, zerotea/zelnet=multi-arch tester images), and
      spec.build.sdkObject (desktop macOS SDK). server renders a <project>-ci-artifacts log-archive
      ConfigMap + archiveLogs on staging; desktop adds the sdk/devSha/buildTemplate/testTemplate params
      and a 3600s staging deadline. Package keyset defaults to build read promote (the provision Job mints
      the gpg <project>-signing-key). Parity-gated against the retired projects/{zdns,zelnet}/ dirs.

    Included changes (v0.1.13 -> v0.1.14)

    • f6cf4cd771ba feat(render): server-package + desktop-package renderers (4th + 5th taxonomies)
    Downloads
  • v0.1.13 43963859cf

    v0.1.13 Stable

    gitea_admin released this 2026-07-06 13:08:05 +00:00 | 227 commits to main since this release

    Added

    • ibmi-rpg renderer — the third rendered taxonomy (internal/render/templates/ibmi/). Objects()
      now renders ibmi-rpg PipelineProjects: the CI + staging sensors compile on a real IBM i (pub400)
      via pipeline-build-ibmi, staging tests + packages the release *SAVF via
      pipeline-test-ibmi-behavioral, and — the structural delta from the buildkit taxonomies — a THIRD
      <project>-deploy sensor fires on main-push and promotes the tested objects to prod via
      pipeline-deploy-ibmi (integrity-gated CRTDUPOBJ). No <project>-build-script ConfigMap (the ibmi
      build runs the repo's own scripts/deploy.sh, so buildScriptCM renders the unused sentinel);
      build.script is no longer required for this taxonomy; build.builderImage defaults to the shared
      ibmi-builder pin. Parity-gated against the retired projects/rpg-hello/ dir (incl. the deploy
      sensor). The shared pub400-creds Secret stays a cluster singleton — NOT rendered per-project.

    Changed

    • Incremental release.

    Included changes (v0.1.12 -> v0.1.13)

    • 11ce50901262 fix(changelog): restore the [0.1.13] release section
    • 03fbfc08319d feat(render): ibmi-rpg taxonomy renderer (third rendered taxonomy)
    • c5045b2860ab fix(render): declared staging sensor excludes the cadence PR-merge commit (no duplicate release execution)
    Downloads
  • v0.1.12 6c4b00b2d7

    v0.1.12 Stable

    gitea_admin released this 2026-07-05 19:10:57 +00:00 | 236 commits to main since this release

    Fixed

    • ReleaseSubmitter stage 2 raced the projector. The cadence workflow was change-kind
      release, so the projector projected its Succeeded onto the declared CR before the
      submitter's verdict check — the terminal-phase guard then aborted, and stage 2 (or the
      Skipped close) never ran. The cadence now carries change-kind release-cadence (which the
      projector does not project); the submitter is the sole phase-writer for stage 1 and closes the
      CR explicitly on cadence Failed/legacy/unsupported-taxonomy paths.

    Included changes (v0.1.11 -> v0.1.12)

    • bd841aace215 Merge remote-tracking branch 'origin/trunk' into feat/change-model-phase2
    • cb6a55c50372 fix(change-model): cadence wf is change-kind release-cadence — submitter owns stage-1 phase (stage 2 no longer races the projector)
    Downloads
  • v0.1.11 ae4a560f0b

    v0.1.11 Stable

    gitea_admin released this 2026-07-05 18:29:28 +00:00 | 242 commits to main since this release

    Added

    • CHANGE-MODEL Phase 2 ("declare intent") — operator side. All three Change CRDs gain
      spec.declaredBy (sensor|shipd|pipectl|cadence; empty = projector-born); PipelineBuild gains
      spec.trigger, PipelineDeploy spec.apps, PipelineRelease's spec.version becomes optional
      (a ship-intent CR is created before the cadence resolves the version). New ReleaseSubmitter
      drives a declared PipelineRelease in two stages: submit the release-cadence workflow, then —
      once it emits {version, sha, outcome} outputs — fill the CR spec and submit pipeline-staging
      with EXPLICIT {version, sha, mode=release} (a no-delta ship closes as Skipped). New
      DeploySubmitter submits pipeline-deploy from a declared PipelineDeploy, parameterized by the
      new PipelineProject.spec.deploy.run. Operator-submitted workflows carry
      pipelines.sean.farm/change-cr/change-kind labels; the projector routes their status to the
      named CR directly, bypassing Classify (heuristics stay only as the legacy fallback).
    • Per-project cutover gate PipelineProject.spec.intentMode: projected|declared. Declared
      rendering: the CI sensor k8s-triggers the PipelineBuild at push time (declaredBy: sensor,
      trigger: push), the staging sensor excludes the operator-submitted release: commit, and
      the cadence renders as a CronJob creating a PipelineRelease CR instead of a CronWorkflow.
    • PipelineProject.spec.plumbingBranches — the CI sensor's release-machinery branch
      exclusions as data (default set unchanged, byte-identical rendering).

    Included changes (v0.1.10 -> v0.1.11)

    • d3a104317165 fix(change-model): unsupported-taxonomy declared release stays on the sensor path (no error loop)
    • f425d1b68f27 Merge remote-tracking branch 'origin/trunk' into feat/change-model-phase2
    • 00847cfd069a feat(change-model): Phase 2 declare-intent — declaredBy CRD fields, Release/Deploy submitters, projector fast path, declared sensor rendering
    Downloads
  • v0.1.10 8aab5743a0

    v0.1.10 Stable

    gitea_admin released this 2026-07-05 17:28:22 +00:00 | 250 commits to main since this release

    Added

    • PipelineRelease.status.failedStep records which step a Failed release died at (e.g.
      promote), surfaced on the query service's ReleaseLeg.failedStep. It's status METADATA — a
      step name, never a log: a release run's promote/sign/devbump steps hold Forgejo push
      tokens and signing keys, so their LOGS are default-denied from the dashboard's credential-safe
      allowlist, which left a Failed release showing only green safe-step chips with nothing marking
      where it broke. The projector's failedStepFromWorkflow walks the failed workflow's Pod nodes
      and records the leaf failure's displayName (latest attempt wins on a retry); it tracks phase
      (cleared on a Succeeded re-run), never sticky. The dashboard uses it to render a
      "failed at <step> — log withheld" marker without exposing any bytes.

    Included changes (v0.1.9 -> v0.1.10)

    • 45b45b528ad8 feat(projector): record PipelineRelease.status.failedStep for Failed releases
    Downloads
  • v0.1.9 5b77343bb9

    v0.1.9 Stable

    gitea_admin released this 2026-07-05 16:35:58 +00:00 | 256 commits to main since this release

    Added

    • GET /panes?project=<p>[&limit=N] on the query service — the dashboard's per-project pane
      feed.       Returns ALL retained Build/Release/Deploy records (newest-first by the same activity
      ordering /status uses; optional per-kind limit), so the pipelines dashboard can retire its
      wf-poller pbuild/prel/pdep TSV projections — the last client-side copy of the record shape.
      The leg structs additively gained sha, startedAt, finishedAt (and short on releases),
      all omitempty so existing /trace//status consumers are unaffected.

    Included changes (v0.1.8 -> v0.1.9)

    • 3e510820307d feat(query): GET /panes — full per-project pane feed for the dashboard
    • b19a85a0a817 fix(cicd): auto-resolve CHANGELOG land conflicts via .gitattributes merge=union
    • acad0ed26120 fix(ci): pin golang:1.26 builder base by digest
    Downloads
  • v0.1.8 45f017e680

    v0.1.8 Stable

    gitea_admin released this 2026-07-05 09:02:32 +00:00 | 265 commits to main since this release

    Added

    • Read-only query service — the ONE server-side Build→Release→Deploy join (traceability Phase C
      back-end).       A new HTTP surface embedded in the operator (internal/query, a non-leader manager
      Runnable on :9090, so every replica serves) reads the projected Change CRs straight from the
      manager cache and answers:
      • GET /trace?project=&ref= — resolves ref (a commit sha, vX.Y.Z, or a Forgejo /commit/
        permalink) and returns the joined chain: build + release (incl. the first tagged release
        containing         a non-release commit via a Forgejo compare walk) + deploys, plus — the capability
        no single-project client surface has — the cross-project carrier leg: it follows a deploy's
        carrierProject/carrierSha into the carrier gitops project's own deploy CR (e.g. an operator's
        v0.6.1 → the seanfarm@<sha> deploy that moved its Flux pin).
      • GET /status?project= — the latest build/release/deploy + tracked counts.
        This is the single implementation the dashboard SPA and pipectl will consume, replacing the three
        hand-synced client copies of the join (SPA JavaScript, pipectl python, the poller go-templates).
        Reachable only via the dashboard nginx (same-origin, behind oathkeeper) and the RBAC-gated apiserver
        service-proxy — plain in-pod HTTP, no new RBAC (the manager already has get/list/watch on the CRs).

    Changed

    • Forgejo client lifted to a shared internal/forgejo package (New/Get/Raw/TagSHA/Tags/
      Compare) so the pin resolver AND the query service use ONE anon-read client with one CA-trust
      setup — never two copies. Pure move: pin-resolver behavior unchanged (its envtest coverage still
      passes against the shared client).
    Downloads