Hello there, As some of you may be aware, I have been working part-time on a project called Tagger [1]. Its goal is to provide an image management abstraction layer for Kubernetes. Tagger tries to mimic (to some extent) the behavior of OpenShift's Image Streams but on a vanilla Kubernetes cluster. Among its features, I can list: - Automatic deployment whenever a new image is pushed. - Allow for easy rollback and roll forward among distinct versions (generations) of the same container image (today’s “latest” vs yesterday’s “latest”). - Kubectl plugins for pushing and pulling images directly to the cluster (an attempt to abstract the registry existence, currently supports “podman” container storage). - Integration with quay.io and docker.io webhooks. I have recorded a brief presentation (~8min) on what Tagger can achieve [2]. Now to the meat of this email: I have been thinking about what the next step for the project is and it seems to me it might be a good fit for tighter integration with shipwright as an opt-in feature. Some points where I think Tagger could be beneficial when used together with shipwright: - Trigger new builds whenever a new Image is pushed. - Should one’s build be triggered every time a new base image shows up? We can cover it. - Provide shipwright with a local container storage volume with all images needed before a build - This is an idea I have been thinking about: an init container that pulls everything locally before the actual build takes place. - Builds won't need to pull images as they will be all there. - Capture the build output image and publish it. - If there are deployments associated with the image why not trigger them? I have gone a long way but I am still far from reaching the end of it. If any of you think that this is an entertaining idea, please reach out. I want to give this project a place where it can deliver value to users. :-) [1] https://github.com/ricardomaraschini/tagger [2] https://youtu.be/HZZeFLooeUM