Move to prebuilt devcontainer.

[metcalfc]

Addresses #201.

Pull Request Title

Description

This change pulls the devcontainer out of Daytona for two reasons:

• Prebuilding
• Reuse across all the provider plugins

Type of Change

• [ ] Bug fix (non-breaking change which fixes an issue)
• [X] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] This change requires a documentation update

Checklist

• [X] I have performed a self-review of my own code
• [X] I have commented my code, particularly in hard-to-understand areas
• [X] I have made corresponding changes to the documentation
• [X] My changes generate no new warnings

Related Issue(s)

This PR addresses issue #201

[Tpuljak]

@metcalfc I like the initiative. Just rebase with main please to resolve the conflict.

[metcalfc]

@vedranjukic or @zzorica can you add a review to close out this? I've rebased it.

[vedranjukic]

@metcalfc is there a way we can still keep the Dockerfile in the repo?

build.cacheFrom

also if we supply an official image it would be multiarch?

[metcalfc]

I can check what ways might keep it in the repo. The devcontainer file in this repo consumes the prebuilt. So there would be a separate directory with the files.

One reason it makes sense to take it out is this repo implies that artifacts in here are the product. ghcr.io/daytonaio/daytona is the daytona container right? Not the dev container for the project.

The devcontainer is multiarch (x86/arm) and the images are built and pushed for both.

[metcalfc]

One clarifying comment, part of the extraction is to also serve as a common base for all the plugins. I think the dev container community is early in deciding how best these are arranged but its not a prebuilt as in codespaces prebuilds which actually would include the postcreate.

This is more its a dev container as a product not a file.

[vedranjukic]

I looked into build.cacheFrom option, but since it doesn't cache the features it doesn't solve the performance problem as features setup takes the most time.

[vedranjukic]

As for moving a dev env config into a separate repo as a common base for plugins - I was thinking on making a bootstrap project for developing a Provider, that would create a "hello world" example, have a running Daytona server in the background, setup debugging etc. Let's move forward in this direction.

[Tpuljak]

As for moving a dev env config into a separate repo as a common base for plugins - I was thinking on making a bootstrap project for developing a Provider, that would create a "hello world" example, have a running Daytona server in the background, setup debugging etc. Let's move forward in this direction.

@vedranjukic This is a good idea but doesn't really have anything to do with this PR. I think improving the build time of the dev container can't hurt us and think we should accept this PR.

@metcalfc a rebase is required.

[vedranjukic]

@Tpuljak having a docker image instead of docker file will not improve the build time significantly because features installation takes most time in the build process.

[Tpuljak]

@Tpuljak having a docker image instead of docker file will not improve the build time significantly because features installation takes most time in the build process.

@vedranjukic that's the point. There are no features in the proposed changes. The features are built into the image.

[Tpuljak]

Chad tested the speed, you can find the insight in #201.

[metcalfc]

The long and short of it which is described more fully in #201 is built time from clean goes from 4.5m to 35s.

[Tpuljak]

@metcalfc reminder to rebase with main.

[metcalfc]

@Tpuljak rebased

[Tpuljak]

@vedranjukic let's get your approval here and we're good to go.