Feature summary (what you would like to be able to do and where):
Currently the builds-api returns the image that was published e.g.
{
"build": {
"repository": "https://github.com/cluebotng/external-grafana-alloy.git",
"ref": "refs/tags/v0.1.7",
"use_latest_versions": true
},
"run": {
"command": "run-alloy",
"cpu": "0.5",
"emails": null,
"filelog": null,
"filelog_stderr": null,
"filelog_stdout": null,
"memory": "0.5Gi",
"mount": null,
"port": 8118,
"replicas": null,
"health_check_script": null,
"health_check_http": "/health"
},
"component_type": "continuous"
}I would like to know exactly which image was published so it can be retrieved via tag and/or digest (see https://github.com/opencontainers/image-spec/blob/main/descriptor.md#digests).
Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
With the tag always set to latest and no digest provided it is impossible to assert that a retrieved image (job execution, component configuration, local test) was produced from a build.
There is also the case that multiple builds can overwrite the same image, which when used from scripts/jobs-cli/components-api ends is all sorts of potential conflicts and confusion.
There is also currently workarounds such as the restart logic in components-api to handle a changed image is not changed as far as e.g. jobs-api is concerned, because the image configuration is identical (x-ref T403321).
Benefits (why should this be implemented?):
- Enhanced security (specific, known, output can be re-used and checked for e.g. sbom contents)
- Reduce consumer logic (no workarounds to infer a build changing, it changed or didn't)
- Easy mapping of which images are in-use (e.g. jobs-api -> builds-api -> harbor <> kubernetes)