With #45261 we switched to storing "per-job" image dumps as artifacts in the jobs from GitHub registry - this also means that we cannot use Commit SHA TAG to pull the image from registry when we want to reproduce a CI job environment.
For now we can do it manually - by downloading the artifact and using breeze ci-image load --image-file <file> - but this can be all easily automated.
The load command could have optional --from-job <JOB> and --from-pr PR flags that could use GiHub API to find and download the right artifact before loading. For JOB - it would take it from the JOB, from PR it would load it from the latest JOB for the PR.
We would also add diagnostic to error out if the image is not with the right platform (for now only linux/amd is supported) and in the future when we add ARM support via ARC (#44512) - we should be able to also produce and store ARM image as artifact, and in this case we would just find and use the right one depending on the platform we are in.
With #45261 we switched to storing "per-job" image dumps as artifacts in the jobs from GitHub registry - this also means that we cannot use Commit SHA TAG to pull the image from registry when we want to reproduce a CI job environment.
For now we can do it manually - by downloading the artifact and using
breeze ci-image load --image-file <file>- but this can be all easily automated.The
loadcommand could have optional--from-job <JOB>and--from-pr PRflags that could use GiHub API to find and download the right artifact before loading. For JOB - it would take it from the JOB, from PR it would load it from the latest JOB for the PR.We would also add diagnostic to error out if the image is not with the right platform (for now only
linux/amdis supported) and in the future when we add ARM support via ARC (#44512) - we should be able to also produce and store ARM image as artifact, and in this case we would just find and use the right one depending on the platform we are in.