Enhancement Request: Customizable RestartPolicy for kpack Build Pods

[dhruvbehl]

Context

I am eager to propose an enhancement to the kpack open-source project that allows users to have control over the customization of the restartPolicy for kpack Build Pods. Presently, the restartPolicy is not adjustable and is fixed at Never, which may not always align with the diverse requirements of our open-source community.

The capability to customize the restartPolicy for Build Pods would significantly enhance flexibility and management control in different use cases. This enhancement would empower users to fine-tune the behavior of Build Pods according to their specific needs. By doing so, we can effectively address scenarios where Build Pods fail due to issues like image repository unavailability, thus improving error handling.

Example Scenario

In my own experience, I've been utilizing kpack in conjunction with the AWS ECR controller to initiate the creation of a repository on Amazon Elastic Container Registry (ECR) for images about to be built. Occasionally, there are timing discrepancies where the repository gets created slightly later than the Build Pod expects it to be available. This situation results in Build Pod failure at the prepare phase.

It would be highly beneficial, if the restartPolicy of the Build Pod could be customized or, at the very least, set to OnFailure as a default option. This customization or default setting adjustment would enable reiteration in case of failures, enhancing the robustness and adaptability of the kpack project for a broader range of use cases.

[tomkennedy513]

My main concern with this would be perpetual retries even for issues that should be terminal like compilation failures. We have been tossing around the idea of retrying particular steps of the build as opposed to the entire build. How would you feel about something like that.

[dhruvbehl]

@tomkennedy513 Can we expect this support anytime soon in the coming releases?

[tomkennedy513]

I think the next step would be an rfc proposing the change since this will be a pretty fundamental change. I am not sure exactly when we plan on doing it, but it is something we are actively thinking about prioritizing. We would also happily accept an rfc if this is something you'd be interested in