{
    "build": {
        "dockerfile": {
            "path": "./Dockerfile",
            "context": "."
        },
        //  optional
        "prebuilds": []
    }
}

Upon workspace project create - a build process will start if defined. The resulting image can be published to the remote container registry (such as Docker hub, ECR, etc.) or can be published to the local container registry that is a part of the server process.

The provider should execute the image builder. That allows the infrastructure-specific build artifacts that the provider is designed for.
For example on platforms where the project container is the compute instance, the project volume must be mounted to persist the data across the project container lifecycle. The project folder must be an artifact (persistable volume) that can be reused for multiple workspace project instances.
To support this we need to define the image builder service and extend the provider interface to support the image builder.

After a few iterations, the build image step is done before the Provisioner is executed. The build step is under the Workspace service context. That allows the Builder to alter the Project configuration.
Altering the Project configuration is needed because additional configuration information becomes available after the build step is completed (like post create and post start commands).
Enabling the automatic detection of the development environment configuration requires the Project configuration to change after the build step as well. If the "empty" build property is defined in the Project configuration - Daytona will read it as autocomplete true. If the development environment configuration is detected, the Project configuration will be updated.

Once the Project image is built and published to a Daytona container image repository, the image name is updated in the Project configuration. Besides the image, the user property is also updated. Suppose the user name value can not be determined from the development environment configuration or the build process. In that case, it must be predefined in the Project configuration upon the Workspace creation.

Once the Project image is built for the commit sha, it will be reused on the next Project instance from the same commit sha. Later, we should improve the Builder to reuse the previous build if possible to optimize the build process and reuse the prebuilt environment.

Lastly, the Remote Builder(s) feature must be implemented to allow scaling and multi-platform builds.

With #531 completed, Daytona can create a Workspace Project based on the dev container configuration with some limitations. Docker-compose within devcontainer.json is not supported. Rebuilds of the devcontainer.json changes need to be implemented as well. Additional configuration settings, such as run arguments and additional volume mounts, must also be supported.
Other configuration formats, such as Dockerfile/Docker-compose and Nix are planned.

Comments and suggestions are welcome :)