build
build copied to clipboard
shipwright-io
Local-Copy vs. Output-Image Overwrite
I would like to raise something for discussion, please. The initial use-case indented for a "Local Copy" BuildSource is to aid the developer's inner loop, however, at the end of this process, the final image would be built from the primary repository branch (for instance main).
With that said, should we validate the BuildRun resources having LocalCopy declared and make sure the .spec.output.image is different than on the Build object?
Let me know your ideas on this, please. It might overlap other subjects like the automatic generation of image tags, and such.
Yep, +1. I also had this concern but not a good idea so far. Enforcing the BuildRun to specify an image makes imo sense if the Build specifies sources. The Build could also be intentionally created to use local sources and have no source/sources set (should be possible). Then, it is fine if the BuildRun that uses LocalCopy does not overwrite the output image.
This could be an opt-out behavior on controller level (= configuration option).
Yep, +1. I also had this concern but not a good idea so far. Enforcing the BuildRun to specify an image makes imo sense if the Build specifies sources.
Indeed! When the BuildRun provides .spec.source or .spec.sources[] overwriting the original parent Build repository... the admin should be able to prevent this behavior.
The Build could also be intentionally created to use local sources and have no source/sources set (should be possible). Then, it is fine if the BuildRun that uses LocalCopy does not overwrite the output image.
Indeed! When the parent Build is set to LocalCopy by default, the BuildRun should be able to push over the Build's .spec.output.image.
This could be an opt-out behavior on controller level (= configuration option).
Yes, indeed. I liked the scenarios you describe here, those should be covered as extended Build Controller validation, and, also have a toggle flag via the regular configuration methods.
From grooming, we would like to continue discussing here, before moving an actionable item to any milestone.
