Simplify and consolidate image building in neighbors.

[dekiel]

Description

With current setup for our team we have multiple tools to build oci images and multiple locations to store information which images to build and how to do it?

Tools to build.

• We build images with ko https://github.com/kyma-project/test-infra/blob/main/.koapps.yaml
• We build images using buildx https://github.com/kyma-project/test-infra/blob/main/images/build-images.sh
• We build images using image-builder https://github.com/kyma-project/test-infra/tree/main/cmd/image-builder

Locations in kyma-project/test-infra we store information about images to build.

• cmd/image-builder/images
• images
• prow/images
• .koapps.yaml

All neighbors images should be build with the same tool. Preferred tool should be SLC-29 certified image building solution. All neighbors images definitions should be stored in location according to one team policy. The policy should define clear guideline where and how to store image definition. This should be a one central location for all images or each image should be stored along with application code it runs or is used by.

Reasons

Our build image setup uses multiple different technologies and doesn't follow any clear rules where to store images definitions. This brings unnecessary complexity, increase maintenance workload and learning curve.

Acceptance Criteria

• [ ] All images are build with image builder using Github Actions
• [ ] A policy about location to store images definitions exists
• [ ] All image definitions are stored in a location aligned with policy

[Ressetkk]

Ko is used to not use Dockerfiles in go apps, greatly simplifying maintenance of go-based images and keeping central standard in build environment for each application. When you build go application you don't have to care about writing a Dockerfile, maintaining it, bumping or writing yet another configuration in dependabot, when the tool can provide everything based on centralized source with separate processes.

docker build in testimages is used to build images that are supposed to be base images and environment images in organization-wide configuration, hence the name "testimages" and to consolidate task of building and pushing image into one job. You just add a dockerfile if needed, and you are done with its own security and maintenance process specific for Docker-based images.

Image-builder is used only for legacy stuff, that is hard to move, like slackmessagesender, which is written in Python. And is used as a substitution for docker-less image building for other teams. It requires its own set of improvements, but there was no real progress there.

---

Keeping this structure is logical and beneficial for development work, speeding up maintenance across multiple applications that you have to maintain.

[Sawthis]

I just wonder if it is worth to migrate test/base images as we will not maintain them in the long-term. But it depends on the effort of migration.

[akiioto]

I don't actually see the pros with using redundant dockerfiles. ko simplify a lot building process, consistency and dependency management.

[dekiel]

@akiioto we never had redundant dockerfiles. We always had one and only one dockerfile for each image. Same as you have one line in ko.yaml and koapps.yaml files for each image. I don't see a reason we should have redundant dockerfiles. Why you think we need redundant dockerfiles?

Could you please share more details how ko improves dependency management?

With simplify a build process that is true if you have only golang images which doesn't require any custom base images. If that is not true then you have to use ko as an additional building tool, which is not a simplification.

About consistency I agree, but it again limited to golang apps images only. Anything else will not benefit from that.

[github-actions[bot]]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically closed due to the lack of recent activity. /lifecycle rotten

[TorstenD-SAP]

Still relevant and necessary to deprecate prow.