Containerize project : configure dockerfile and compose files

[sujal-goswami]

resolve #740

For user to build this project using docker they need to fulfil the prerequisites:

Prerequistes

• Docker Desktop or docker should be installed
• WSL - Windows Subsystem for Linux (only for windows users)
• should have X server installed in host machine
  if not have then can download from command sudo apt-get install x11-xserver-utils.
  to check its correct installation run xhost this should give output as

access control disabled, clients can connect from any host
LOCAL:
SI:localuser:wslg

demo image

References

cypress-io/cypress-documentation#5816
--no-sandbox error

[CLAassistant]

All committers have signed the CLA.

[esimkowitz]

Thank you for setting this up! Since this is for a dev container, I think the .dockerignore doesn't need to be as restrictive, since the developer may care about the .md, config, and Yarn files. Otherwise it looks good to me!

[esimkowitz]

Based on your issue, I assumed you meant to create a docker container for development purposes, usually for something like this you would want to add the VSCode tooling for Dev Containers and leave the repo data inside the final container. (see Developing inside a Container

I'm not sure I see a point to just running our app in a container, since it won't have access to the rest of your system, which kind of defeats the purpose of a terminal app.

[esimkowitz]

Could you verify that this complies with the guidelines for the dev containers in the guide I linked (Developing inside a Container)? This one may also be helpful: Create a development container. I think you can skip setting a CMD to start on container run, since this is not necessary for developing inside a container. Also I realize the suggested changes I made left a bunch of new lines, could you clean those up?

[sujal-goswami]

Sure !

[sujal-goswami]

now I think it is good to go; now, the user can use the VS Code dev container feature for seamless development in the container with pre-install go , eslint and prettier extensions in it.

[esimkowitz]

I don't think you need to build the app at all in the dockerfile, since it's fast enough. Also, because webpack-watch is blocking, the dockerfile never completes. I moved this to the "postStartCommand" in devcontainer.json, but I'm still unable to launch the app, as it's complaining about DBus not being started. I tried moving the service dbus start command to the postStartCommand too, but it's still not working. What host OS are you using to test this? I'm on macOS 14.

I'm concerned that if the devcontainer isn't reliable on all platforms or requires additional hoops to get working, it won't be that much better than just installing the deps directly. Aside from scripthaus, we don't have any crazy dependencies. We're also in the process of a pretty large rearchitecting and we're removing the scripthaus dependency as part of this, so our dependency story will get a lot simpler.

[sujal-goswami]

I don't think the host OS is the issue here. It's more likely an issue with the dbus service. I encountered a similar dbus error during my testing but resolved it by running service dbus start on the machine. You can refer to this link for more details. By the way, I'm using Windows as the host OS, so it's odd if the OS is indeed the problem. The rearchitecting plan sounds great! Simplifying the dependencies will definitely streamline the process.

[klmcwhirter]

FWIW, I did something similar as this PR - but, my goal was to build waveterm in a container - not run it in the container.

I purposely do not install multiple tool chains, project specific dependencies, etc. on localhost.

FYI, I am running on Fedora 41 and typically use VS Code (although I have been using emacs -nw again lately.

I concur that .devcontainer might be of dubious value, and there are several missing extensions that I typically use for web dev (vscode-tailwindcss, etc.). So I would probably just create my own.

In my case, I chose fedora:41 as the base OCI image because I wanted to be sure the resulting binary would run on my system.

That is not an issue when running in a container. If I was looking for containerization, I would prefer flatpak as an execution env because it is a more natural fit with my use of Fedora.

I suspect there may be a number of personal preferences out there.

But agree with @esimkowitz - thanks for putting in the effort. I am sure there are devs out there who can benefit.