Proposal: rework the OLM build and test pipeline

Summary

The OLM path (Makefile:222-299, .github/workflows/continuous-integration.yml:774-1010, .github/workflows/release-publish.yml:336-490) has drifted:

• operator-sdk, opm and preflight are fetched with curl into bin/ pinned to a release tag rather than a digest — for the tools whose output we ship to OperatorHub.
• olm-bundle bakes docker build --push into the build target (Makefile:238), so it cannot be run without a registry.
• We still build and push the deprecated sqlite index image (Makefile:255-257) alongside the file-based catalog.
• Preflight's pass/fail verdict is a bash loop over jq -r .passed in workflow YAML (continuous-integration.yml:884-892).
• The bundle job is duplicated between CI and release, and has already drifted.
• Most of it is gated to github.repository_owner == 'cloudnative-pg', so forks never exercise any of it.

Proposal

Rework it in three tracks, each independently mergeable:

1. Pin every OLM tool as a digest-referenced container image. No new build-system dependency — this is docker run from the existing Make targets, and it removes the runner-environment workaround at continuous-integration.yml:820-825.
2. Move the two jobs that need a live environment — scorecard and preflight — into Dagger modules hosted in https://github.com/cloudnative-pg/ci-machinery. The sibling Klio project already runs both (Apache-2.0, CloudNativePG copyright); ci-machinery becomes their home rather than each project carrying a copy. CNPG contributes the OperatorHub submission path in return, which Klio and plugin-barman-cloud will both need.
3. De-duplicate the bundle job between CI and release.

Modules take explicit arguments (--bundle, --image, --version) and never read environment conventions — that is what lets a Make-based consumer and a Taskfile-based one share them.

Non-goals

Adopting Taskfile, changing what we publish to OperatorHub, touching non-OLM CI. make olm-bundle and make olm-catalog remain the entry points, so release branches are unaffected and nothing here needs backporting.

Additional tickets needed

In this repository:

• Pin OLM tooling as digest-referenced container images.
• Stop building and pushing the deprecated sqlite index image.
• Consolidate the duplicated OLM bundle job between CI and release-publish.
• Adopt the shared scorecard module.
• Adopt the shared preflight module.
• Adopt the shared OperatorHub (kiwi/lemon/orange) test module.

In cloudnative-pg/ci-machinery:

• Seed the repository with the shared OLM Dagger modules.
• Add the OperatorHub community-operators test module, extracted from CNPG.

Tracked separately by their own maintainers, and not part of this proposal, but listed so the shared-repository case is visible in full.

In cloudnative-pg/klio:

• Migrate to the shared scorecard and preflight modules, retiring its local copies.
• Adopt the OperatorHub test module and submission path.

In cloudnative-pg/plugin-barman-cloud, which has no OLM packaging at all today — it ships a manifest.yaml attached to each release — and an open community request for it (cloudnative-pg/plugin-barman-cloud#554):

• Add OLM bundle and catalog generation, built on the same pipeline shape.
• Adopt the shared scorecard, preflight and OperatorHub test modules.

It is already a Dagger and Taskfile consumer (dagger/{e2e,gotest,check-doc-version}), so the shared modules are the cheapest part of that work; the bundle packaging is the new ground.

graph TD
  subgraph CNPG["cloudnative-pg/cloudnative-pg"]
    A["Pin OLM tooling as container images"]
    B["Drop the deprecated sqlite index image"]
    C["Consolidate the duplicated bundle job"]
    E["Adopt the scorecard module"]
    F["Adopt the preflight module"]
    G["Adopt the OperatorHub test module"]
  end
  subgraph CIM["cloudnative-pg/ci-machinery"]
    D["Seed the shared OLM Dagger modules"]
    H["Add the OperatorHub test module"]
  end
  A --> B
  D --> E
  D --> F
  D --> H
  H --> G

Consolidate the duplicated bundle job has no dependencies. The ci-machinery work can start immediately, in parallel with the tooling changes; only the three adoption tickets block on it.