Explore how to simplify process of customizing Dockerfiles

[chrmarti]

Tracking our plan item.

[chrmarti]

I'm adding the picker I previously prototyped for Dockerfile ARGs with a boolean default value. The picker will be shown at the end of the 'Add Configuration' flow, e.g. (artificial):

For an ARG variable to be shown in the UI it must be preceded by a comment line starting with # [Option] followed by a description that will be used as the label in the picker and its default value must be "true" or "false" (with or without double quotes). Currently none match, so we can start using this when we decide to.

[Chuxel]

Nice - Love it!! I can add a round of updates.

Are you thinking this would also cover the "VARIANT" ARG or are you thinking you'll lift that from the README (or some other concept)?

[chrmarti]

VARIANT would be great too, this will add another step to 'Add Configuration', but I think it's worth making this easy to discover.

The advantage of weaving this into the Dockerfile would be that we can rerun these config steps at the user's request and hopefully flatten the learning curve further. The advantage of adding it to the metadata in the README could be that we can make it JSON and have it well-specified also for advanced cases. I'm currently leaning towards adding it to the Dockerfile. What do you think?

[chrmarti]

Adding the following syntax to experiment with:

# [Choice] Node.js version: 10, 12, 14
ARG VARIANT="14"

We can switch it to use the metadata if that is seen as preferred. The # [Choice], : and ,s are part of the syntax. The UI then is:

[bamurtaugh]

I really love this too!

I definitely agree covering VARIANT makes sense- even with another step to "Add Configuration," it helps achieve our goal to automate the entire flow of installing something new.

I expected to find information that shows up in this picker originally in the Dockerfile- as Christof mentions, I think the picker does a great job of flattening the learning curve, and as users become more advanced, they can better understand what the Dockerfile does, how it's populating the picker, and how they can customize it to fit their needs.

I see the benefits of including it as metadata in the README, but since ARGS and VARIANT live in the Dockerfile, and there can already be some confusion about the differences between how to use Dockerfile versus devcontainer.json, I think it'd make sense to stick to the Dockerfile and minimize introducing content in another location.

[Chuxel]

Cool! I can do a round of updates to add that in.

BTW - Are you pulling the default value from the Dockerfile or devcontainer.json? Some of the base.Dockerfiles have different values that are intended for the image build rather than users. I should be able to get the user Dockerfile to have the same defaults, but wondering which is used for figuring out the default vaules.

[PavelSosin-320]

And it finally leads to not so new concept of Development machine's receipt, like in Eclipse/Che and other cloud-based solutions. The Che receipt is one of the fundamental Development artifacts which is managed in the Source repository and assigned to a workspace during workspace initialization. ... In the end, the User can move its workspace to any place where only 2 pre-requisites fulfilled: Git client and Docker to re-create Dev-machine. Docker registry container is available or can be installed in any place where Docker runs. Docker-compose or Docker stack deploy can run Dev-machine on the Docker universally. This old solution easily fulfills the serverless concept requirements.
Of course, it marks the end of the client-server paradigm because the user doesn't need a server, only docker ( available on Windows Home since May)

[chrmarti]

@Chuxel I read both the Dockerfile and the devcontainer.json to determine the default value. I then write the user's picked value to the devcontainer.json only if that is not the same as the default value. (So you can have options in the Dockerfile that are not visible in the devcontainer.json unless the user picked a value different from the default.)

[PavelSosin-320]

If so, any Dockerfile change will create a new Dev container image stored locally. But local images have limited usage, they are not always useful in docker-compose or docker stack deploy. It can take a long time to re-build them. But Docker registry container is always available for everybody who uses docker. If new tagged variant produces a new tagged image. Tt worths pushing it to the local or proxy registry and reuse the ready dev-container tagged image from the local registry instead of building them taking a risk that variant build will fail. In the last case, the developer will have plenty of free time until working variant will be available.

[chrmarti]

@PavelSosin-320 The 'variant' usually has its own base image, so the local Dockerfile might look like: https://github.com/microsoft/vscode-dev-containers/blob/77b4d98bb34dd1c83a45ff9e331e5becc4a7cbb2/containers/javascript-node/.devcontainer/Dockerfile#L1

[Chuxel]

@chrmarti I've now updated the definitions with a [Choice] value! This is really cool. Might be worth spinning up a feature request to do this for Compose. We could do the exact same thing with args in the compose files referenced which would be pretty amazing.

Edit: In fact, I can proactively go add them even though they won't be picked up initially.

[chrmarti]

Closing this issue as the tracking item for August, thanks.