Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
basil opened this issue May 25, 2023 · 8 comments · Fixed by #1635
Closed

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

basil opened this issue May 25, 2023 · 8 comments · Fixed by #1635
Labels

Comments

@basil
Copy link
Member

basil commented May 25, 2023

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Member Author

basil commented May 25, 2023

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
Copy link
Member

timja commented May 25, 2023

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

@dduportal
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Member Author

basil commented May 25, 2023

let’s also stop building an unused image

It is used by Jenkins core I think.

@basil
Copy link
Member Author

basil commented May 25, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants