e the new flavor in the list of available flavors:zenml image-builder flavor list

It is important to draw attention to when and how these base abstractions are coming into play in a ZenML workflow.

The CustomImageBuilderFlavor class is imported and utilized upon the creation of the custom flavor through the CLI.

The CustomImageBuilderConfig class is imported when someone tries to register/update a stack component with this custom flavor. Especially, during the registration process of the stack component, the config will be used to validate the values given by the user. As Config objects are inherently pydantic objects, you can also add your own custom validators here.

The CustomImageBuilder only comes into play when the component is ultimately in use.

The design behind this interaction lets us separate the configuration of the flavor from its implementation. This way we can register flavors and components even when the major dependencies behind their implementation are not installed in our local setting (assuming the CustomImageBuilderFlavor and the CustomImageBuilderConfig are implemented in a different module/path than the actual CustomImageBuilder).

Using a custom-build context

The BaseImageBuilder abstraction uses the build_context_class to provide a class that should be used as the build context. In case your custom image builder requires a different build context than the default Docker build context, you can subclass the BuildContext class to customize the structure of your build context. In your image builder implementation, you can then overwrite the build_context_class property to specify your build context subclass.

PreviousGoogle Cloud Image Builder

NextAnnotators

Last updated 19 days ago