Cannot make changes to the ATH image and its consumers in the same code change

[basil]

As of #1168, the ATH image used for a test run is not the same as the code under test (CUT), thereby breaking the ability to make changes to the ATH image and its consumers in the same code change. This effectively nullifies testing of changes to the ATH image. Rather the ATH image should be built once from the code under test (CUT) and then consumed from each of the parallel test branches.

[dduportal]

Make sense: does it also mean we should remove the build/push/realase from infra.ci (the other pipeline) as I don’t understand why we need this in the scenario you describe?

[dduportal]

Optionnaly : since the initial idea was to decrease the time spent by a build in the build step, would that make sense to use a build caching for the layers (so if the image does not change often then it would benefit from the layer caching from a registry, effectively reducing the build time)?

[basil]

I am not familiar with the other pipeline: is it publishing images from pre-release (PR) builds to a registry, "incrementals style"? If so, then all that would be needed to fix this issue would be to wait for process to complete and then consume that "incremental" image in each parallel test branch.

[timja]

What about pulling the image and then building the image? Should be a no-op in most cases?

[dduportal]

What about pulling the image and then building the image? Should be a no-op in most cases?

That is the idea of using the layer caching (otherwise you would quickly hit cache invalidation)

[dduportal]

I am not familiar with the other pipeline: is it publishing images from pre-release (PR) builds to a registry, "incrementals style"? If so, then all that would be needed to fix this issue would be to wait for process to complete and then consume that "incremental" image in each parallel test branch.

At first (quick and superficial) sight, it pushes only on tags or « latest » from the principal branch. That is why i do not understand the goal and did #1168.

No problem to revert as I said, but then let’s also stop building an unused image

[basil]

let’s also stop building an unused image

It is used by Jenkins core I think.

[basil]

What about pulling the image and then building the image? Should be a no-op in most cases?

Yeah, if this works, then I think it would be a good enough solution. Builds that don't modify the image would be no-ops, and builds that do modify the image would be slower to the degree that they modify the deepest layers of the image.