CI – Need a complete runtime image inventory for pre-caching (beyond )

Teams running CI on private or VM-based build infrastructure need to pre-cache container images to avoid cold pulls and keep build times predictable.

Today, the API only returns core CI images (lite-engine, ci-addon, some plugins), but all images that can be pulled during real CI executions (for example security job-runners and several plugin/utility images).

As a result, platform teams don’t have a single, reliable source of truth for “all images Harness may pull at runtime.”

---

* Build farms rely on aggressive image caching to keep build times low.

* Because only a subset of images is exposed via , teams have to:

* Discover missing images reactively when pipelines pull something new.

* Manually maintain a pre-cache list that easily goes out of date.

* Frequent image updates or new plugin images can and reintroduce cold pulls, which:

* Increases build times and variance.

* Adds operational overhead just to keep the cache aligned with what Harness actually uses.

---

Provide a way to programmatically retrieve a used by CI and adjacent modules, suitable for pre-caching. For example:

* Extend (via a flag)

* Introduce a new endpoint that returns a including:

* Core CI engine/addon images

* CI plugins (kaniko, buildx, docker/ecr/gcr/gar/acr, artifact-metadata-publisher, etc.)

* Security / STO job-runner images

* SSCA/SCS and other CI-adjacent images where applicable

The response should include image names and tags in a structured format, so platform teams can plug it directly into their image build / cache-warmup workflows.

This would let users:

all* relevant images more reliably.

* Reduce cold pulls and runtime surprises.

* Spend less time chasing down “which image did this pipeline just pull?” and more time actually running builds.