| Message ID | 20241225172019.244601-1-toertel@gmail.com |
|---|---|
| State | New |
| Delegated to: | Stefano Babic |
| Headers | show |
| Series | Add minimal devcontainer | expand |
Hi Mark On 25.12.24 18:14, toertel@gmail.com wrote: > From: Mark Jonas <toertel@gmail.com> > > The devcontainer can build and run all SWupdate tests for x86-64 > targets. It uses ci/setup.sh to install the required build dependencies. > > Suggested-by: Ayoub Zaki <ayoub.zaki@embetrix.com> > Signed-off-by: Mark Jonas <toertel@gmail.com> > --- > .devcontainer/Dockerfile | 33 +++++++++++++++++++++++++++++++++ > .devcontainer/devcontainer.json | 13 +++++++++++++ > .gitignore | 3 +++ > DevContainer.md | 26 ++++++++++++++++++++++++++ > 4 files changed, 75 insertions(+) > create mode 100644 .devcontainer/Dockerfile > create mode 100644 .devcontainer/devcontainer.json > create mode 100644 DevContainer.md > > diff --git a/.devcontainer/Dockerfile b/.devcontainer/Dockerfile > new file mode 100644 > index 00000000..e0f6d84e > --- /dev/null > +++ b/.devcontainer/Dockerfile > @@ -0,0 +1,33 @@ > +# SPDX-FileCopyrightText: 2024 Mark Jonas <toertel@gmail.com> > +# > +# SPDX-License-Identifier: MIT > + > +FROM ubuntu:24.04 > + > +ARG DEBIAN_FRONTEND=noninteractive > + > +# Dummy uid/gid for devuser; will be changed at devcontainer startup > +ARG USER_UID=1234 > +ARG USER_GID=1234 > +ARG USER_SHELL=/bin/bash > +ARG USERNAME=devuser > + > +# Remove ubuntu user to free up uid:gid 1000:1000 > +RUN userdel -r ubuntu || true > + > +RUN groupadd --gid ${USER_GID} ${USERNAME} && \ > + useradd --shell ${USER_SHELL} --uid ${USER_UID} --gid ${USER_GID} -m ${USERNAME} > + > +RUN apt-get update > + > +# Allow devuser to execute any command as root without password prompt > +RUN apt-get -y install --no-install-recommends sudo && \ > + echo "${USERNAME} ALL=(root) NOPASSWD:ALL" > /etc/sudoers.d/${USERNAME} && \ > + chmod 0440 /etc/sudoers.d/${USERNAME} > + > +# Install SWUpdate build dependencies > +COPY ./ci/setup.sh /tmp > +RUN chmod +x /tmp/setup.sh && /tmp/setup.sh > + > +USER ${USERNAME} > +WORKDIR /home/${USERNAME} Maybe we can think about using Podman instead of Docker. Non-root user usage is such a pain with Docker. I'm maintaining my own devcontainer on this branch: https://github.com/d4nuu8/swupdate/tree/container The following commit added the container image which is quite simple: https://github.com/d4nuu8/swupdate/commit/47e8e54451a7f5d352cad288729330759ae8a13a To use Podman us container engine with VS Code one only needs to change the following setting: "dev.containers.dockerPath": "podman" This would eliminate all the user handling in the container and in the devcontainer settings. Just to be complete - the VS Code devcontainer configuration can be found here: https://github.com/d4nuu8/swupdate/commit/653fa66425cee6c5cc5e52a650cdfa233f47a77f Regards Daniel
Hi Daniel, Thank you for your suggestions. > Maybe we can think about using Podman instead of Docker. Non-root user > usage is such a pain with Docker. One benefit of the devcontainer is that Windows users can compile and run SWUpdate as well. Is that also given when using Podman instead of Docker? I found installation instructions for Podman on Windows / WSL2 but I do not know whether it works as well as Docker. > I'm maintaining my own devcontainer on this branch: > https://github.com/d4nuu8/swupdate/tree/container > > The following commit added the container image which is quite simple: > https://github.com/d4nuu8/swupdate/commit/47e8e54451a7f5d352cad288729330759ae8a13a > > To use Podman us container engine with VS Code one only needs to change > the following setting: > > "dev.containers.dockerPath": "podman" I didn't get it working by adding the setting to the workspace' .vscode/settings.json file. Is it possible that this can only be set in the user settings? There, I was able to switch to Podman. That could be a downside because this forces the developers to use Podman for all their devcontainers. Besides that we could not offer an out-of-the-box-experience because manual tweaking of the VS Code user settings is required. And wouldn't then there possibly be other devcontainers which do not work anymore? > > > This would eliminate all the user handling in the container and in the > devcontainer settings. I am not sure I correctly understand the connection between Podman running rootless and what I could skip in the container and the settings. The debian:testing-slim image does not have a regular user, just root. But because Podman runs rootless it runs as the host user which runs VS Code (which runs Podman) and thus root inside the container effectively reads/writes with the uid and gid of the host user. And that's why we could skip adding a devuser and adjusting uid and gid. Right? My experiments show that all files which are externally owned by my user (1000:1000) are internally owned by root (0:0) with Podman. > Just to be complete - the VS Code devcontainer configuration can be > found here: > https://github.com/d4nuu8/swupdate/commit/653fa66425cee6c5cc5e52a650cdfa233f47a77f I got it working with Podman and the Dockerfile and devcontainer.json do not need any of the user handling any more. IMHO it would be great if the dev.containers.dockerPath could be set in the workspace settings. But as a user settings it does not feel right for me. Cheers, Mark
Hi Mark On 26.12.24 19:21, Mark Jonas wrote: > Hi Daniel, > > Thank you for your suggestions. > >> Maybe we can think about using Podman instead of Docker. Non-root user >> usage is such a pain with Docker. > > One benefit of the devcontainer is that Windows users can compile and > run SWUpdate as well. Is that also given when using Podman instead of > Docker? I found installation instructions for Podman on Windows / WSL2 > but I do not know whether it works as well as Docker. It should be doable for every developer to setup a WSL2 distro and install Podman inside of it. The VS Code devcontainer can handle this without any problem. You are able to start VS Code directly connected to the container running in the WSL from Windows. There is a Podman Desktop application available which is actually doing the same thing: https://podman-desktop.io/docs/installation/windows-install If you want to enable "everybody" to develop SWUpdate by using Docker for Windows this would be limited the following group as stated by the license agreement of Docker for Windows: Docker Desktop is free for small businesses (fewer than 250 employees AND less than $10 million in annual revenue), personal use, education, and non-commercial open source projects. See https://docs.docker.com/subscription/desktop-license/ From my point of view Docker is a dead horse and I wouldn't spend any time introducing it anywhere. > >> I'm maintaining my own devcontainer on this branch: >> https://github.com/d4nuu8/swupdate/tree/container >> >> The following commit added the container image which is quite simple: >> https://github.com/d4nuu8/swupdate/commit/47e8e54451a7f5d352cad288729330759ae8a13a >> >> To use Podman us container engine with VS Code one only needs to change >> the following setting: >> >> "dev.containers.dockerPath": "podman" > > I didn't get it working by adding the setting to the workspace' > .vscode/settings.json file. Is it possible that this can only be set > in the user settings? There, I was able to switch to Podman. That's indeed a problem. Right now it can only be set as a user settings. I've requested this to be changed but Microsoft only added it the their backlog so far: https://github.com/microsoft/vscode-remote-release/issues/8817 > That could be a downside because this forces the developers to use > Podman for all their devcontainers. Besides that we could not offer an > out-of-the-box-experience because manual tweaking of the VS Code user > settings is required. And wouldn't then there possibly be other > devcontainers which do not work anymore? I don't think we can ensure everything we are doing here is working for everybody without any change to ones personal setup. Adding documentation for developers how this devcontainer must be used and who VS Code must be configured should be sufficient from my point of view. >> This would eliminate all the user handling in the container and in the >> devcontainer settings. > > I am not sure I correctly understand the connection between Podman > running rootless and what I could skip in the container and the > settings. > > The debian:testing-slim image does not have a regular user, just root. > But because Podman runs rootless it runs as the host user which runs > VS Code (which runs Podman) and thus root inside the container > effectively reads/writes with the uid and gid of the host user. And > that's why we could skip adding a devuser and adjusting uid and gid. > Right? Right. > My experiments show that all files which are externally owned by my > user (1000:1000) are internally owned by root (0:0) with Podman. > >> Just to be complete - the VS Code devcontainer configuration can be >> found here: >> https://github.com/d4nuu8/swupdate/commit/653fa66425cee6c5cc5e52a650cdfa233f47a77f > > I got it working with Podman and the Dockerfile and devcontainer.json > do not need any of the user handling any more. IMHO it would be great > if the dev.containers.dockerPath could be set in the workspace > settings. But as a user settings it does not feel right for me. > > Cheers, > Mark Regards Daniel
Hi Daniel, [..] > It should be doable for every developer to setup a WSL2 distro and > install Podman inside of it. The VS Code devcontainer can handle this > without any problem. You are able to start VS Code directly connected to > the container running in the WSL from Windows. > > There is a Podman Desktop application available which is actually doing > the same thing: > > https://podman-desktop.io/docs/installation/windows-install > > If you want to enable "everybody" to develop SWUpdate by using Docker > for Windows this would be limited the following group as stated by the > license agreement of Docker for Windows: > > Docker Desktop is free for small businesses (fewer than 250 employees > AND less than $10 million in annual revenue), personal use, education, > and non-commercial open source projects. > > See https://docs.docker.com/subscription/desktop-license/ The licensing is a very good argument pro Podman. > From my point of view Docker is a dead horse and I wouldn't spend any > time introducing it anywhere. [..] > >> To use Podman us container engine with VS Code one only needs to change > >> the following setting: > >> > >> "dev.containers.dockerPath": "podman" > > > > I didn't get it working by adding the setting to the workspace' > > .vscode/settings.json file. Is it possible that this can only be set > > in the user settings? There, I was able to switch to Podman. > > That's indeed a problem. Right now it can only be set as a user settings. > > I've requested this to be changed but Microsoft only added it the their > backlog so far: > > https://github.com/microsoft/vscode-remote-release/issues/8817 Thanks for making Microsoft aware of this over a year ago. I keep my fingers crossed that it soon bubbles up in their backlog. > > That could be a downside because this forces the developers to use > > Podman for all their devcontainers. Besides that we could not offer an > > out-of-the-box-experience because manual tweaking of the VS Code user > > settings is required. And wouldn't then there possibly be other > > devcontainers which do not work anymore? > > I don't think we can ensure everything we are doing here is working for > everybody without any change to ones personal setup. It would be interesting to hear what Stefano and Ayoub think about it. I think the manual change of the user settings would be acceptable. I am optimistic that eventually the dev.containers.dockerPath setting could be a workspace setting. I am not aware of a technical reason against it. > Adding documentation for developers how this devcontainer must be used > and who VS Code must be configured should be sufficient from my point of > view. [..] Cheers, Mark
Hi Mark, Daniel, On 12/30/24 17:54, Mark Jonas wrote: > Hi Daniel, > > [..] > >> It should be doable for every developer to setup a WSL2 distro and >> install Podman inside of it. The VS Code devcontainer can handle this >> without any problem. You are able to start VS Code directly connected to >> the container running in the WSL from Windows. >> >> There is a Podman Desktop application available which is actually doing >> the same thing: >> >> https://podman-desktop.io/docs/installation/windows-install >> >> If you want to enable "everybody" to develop SWUpdate by using Docker >> for Windows this would be limited the following group as stated by the >> license agreement of Docker for Windows: >> >> Docker Desktop is free for small businesses (fewer than 250 employees >> AND less than $10 million in annual revenue), personal use, education, >> and non-commercial open source projects. >> >> See https://docs.docker.com/subscription/desktop-license/ > > The licensing is a very good argument pro Podman. > >> From my point of view Docker is a dead horse and I wouldn't spend any >> time introducing it anywhere. > > [..] > >>>> To use Podman us container engine with VS Code one only needs to change >>>> the following setting: >>>> >>>> "dev.containers.dockerPath": "podman" >>> >>> I didn't get it working by adding the setting to the workspace' >>> .vscode/settings.json file. Is it possible that this can only be set >>> in the user settings? There, I was able to switch to Podman. >> >> That's indeed a problem. Right now it can only be set as a user settings. >> >> I've requested this to be changed but Microsoft only added it the their >> backlog so far: >> >> https://github.com/microsoft/vscode-remote-release/issues/8817 > > Thanks for making Microsoft aware of this over a year ago. I keep my > fingers crossed that it soon bubbles up in their backlog. It seems MS does not take very seriously. > >>> That could be a downside because this forces the developers to use >>> Podman for all their devcontainers. Besides that we could not offer an >>> out-of-the-box-experience because manual tweaking of the VS Code user >>> settings is required. And wouldn't then there possibly be other >>> devcontainers which do not work anymore? >> >> I don't think we can ensure everything we are doing here is working for >> everybody without any change to ones personal setup. Agree, we cannot ensure that it works out of the box in any conditions. However, we can add documentation to explain what should be done and how to use it. > > It would be interesting to hear what Stefano and Ayoub think about it. > > I think the manual change of the user settings would be acceptable. I > am optimistic that eventually the dev.containers.dockerPath setting > could be a workspace setting. I am not aware of a technical reason > against it. Probably not a technical reason... Sources are published, but there is no community and there is not a single commit done by someone else but Microsoft. > >> Adding documentation for developers how this devcontainer must be used >> and who VS Code must be configured should be sufficient from my point of >> view. I agree. Best regards, Stefano
diff --git a/.devcontainer/Dockerfile b/.devcontainer/Dockerfile new file mode 100644 index 00000000..e0f6d84e --- /dev/null +++ b/.devcontainer/Dockerfile @@ -0,0 +1,33 @@ +# SPDX-FileCopyrightText: 2024 Mark Jonas <toertel@gmail.com> +# +# SPDX-License-Identifier: MIT + +FROM ubuntu:24.04 + +ARG DEBIAN_FRONTEND=noninteractive + +# Dummy uid/gid for devuser; will be changed at devcontainer startup +ARG USER_UID=1234 +ARG USER_GID=1234 +ARG USER_SHELL=/bin/bash +ARG USERNAME=devuser + +# Remove ubuntu user to free up uid:gid 1000:1000 +RUN userdel -r ubuntu || true + +RUN groupadd --gid ${USER_GID} ${USERNAME} && \ + useradd --shell ${USER_SHELL} --uid ${USER_UID} --gid ${USER_GID} -m ${USERNAME} + +RUN apt-get update + +# Allow devuser to execute any command as root without password prompt +RUN apt-get -y install --no-install-recommends sudo && \ + echo "${USERNAME} ALL=(root) NOPASSWD:ALL" > /etc/sudoers.d/${USERNAME} && \ + chmod 0440 /etc/sudoers.d/${USERNAME} + +# Install SWUpdate build dependencies +COPY ./ci/setup.sh /tmp +RUN chmod +x /tmp/setup.sh && /tmp/setup.sh + +USER ${USERNAME} +WORKDIR /home/${USERNAME} diff --git a/.devcontainer/devcontainer.json b/.devcontainer/devcontainer.json new file mode 100644 index 00000000..9935f7e2 --- /dev/null +++ b/.devcontainer/devcontainer.json @@ -0,0 +1,13 @@ +// SPDX-FileCopyrightText: 2024 Mark Jonas <toertel@gmail.com> +// +// SPDX-License-Identifier: MIT + +{ + "name": "SWUpdate Development Container", + "build": { + "dockerfile": "Dockerfile", + "context": ".." + }, + "remoteUser": "devuser", + "updateRemoteUserUID": true +} diff --git a/.gitignore b/.gitignore index 4755ff07..24e9a38e 100644 --- a/.gitignore +++ b/.gitignore @@ -127,6 +127,9 @@ web-app/swupdate-www.tar.gz !.gitlab-ci.yml !.github +# devcontainer +!.devcontainer/ + # swupdateclient Pipfile Pipfile.lock diff --git a/DevContainer.md b/DevContainer.md new file mode 100644 index 00000000..c8c81e7a --- /dev/null +++ b/DevContainer.md @@ -0,0 +1,26 @@ +<!-- +SPDX-FileCopyrightText: 2024 Mark Jonas <toertel@gmail.com> + +SPDX-License-Identifier: MIT +--> + +# Introduction +The SWUpdate devcontainer is a Docker-based development environment that +ensures consistent tooling and settings across different machines. It uses +configuration files to specify the environment setup and automatically builds +the required development workspace when opened in compatible IDEs like VS Code. + +The devcontainer supports compiling and running SWUpdate for x86-64 targets. + +# Usage +## Compile and run tests +You can compile and run all SWUpdate tests inside the devcontainer. This is very +helpful during development and highly recommend before sending a patch to the +mailing list. + +To compile and run all SWUpdate tests, execute the following command using a +devcontainer terminal. + +``` +ci/test-configs.sh +```