feat: Dockerfile for reproducible dev/ci environment#632
feat: Dockerfile for reproducible dev/ci environment#632fjfnaranjo wants to merge 1 commit intonvim-tree:masterfrom
Conversation
|
This is fantastic! I'll give it a go shortly... |
|
After running a make, the generated files are all owned by root and thus no longer editable. Perhaps we could set the user/group ids similar to https://github.com/alex-courtis/way-displays/blob/675910d3378f6cf85cc3b413a0536ab7a3d1ba84/GNUmakefile#L113-L120 |
|
It looks like make filetypes is not reporting errors, although it seems to execute OK: |
This is a known issue with Docker and users with experience using Docker will know how to run the file as it is now. Docker follows a security model that is closer to how classic Linux servers/daemons work. A server is run as root and you, as a user, can ask the server to run the container using the CLI if you belong to a particular group in the system. They will be run as root and you will get the permission problems. You can install and configure Docker to use unpriviledged containers to avoid running containers as a user that can access you entire system, but regular users just use a parameter to override the user that runs the commands after the You will not need this neither in podman (linux) nor in colima (Mac) because they by default use unpriviledged containers, running the commands as your user without the need to specify I suggest you either switch to them or use the Ideally (and maybe controversial), it is safer to avoid Docker entirely if you are not willing to do the effort of configuring it as unpriviledged (instructions in their site) and just remove it from your system. If you can run this with Take into account that I'm offering a superficial/incomplete description on Docker/Linux's security/server model and the full explanation is more complex. You may be already protected for some of the more common exploits but I don't know your system and I'm doing general assumptions. |
|
Understood. There are many caveats to raw dockerised builds. This is valuable and we should make it available. I've created a skeletal wiki and would be most grateful if you added a section "Dockerfile for reproducible dev/ci environment" or similar to the development page. We can then link CONTRIBUTING.md to the wiki, as we've done with nvim-tree.lua |
|
Do you mind if I propose an alternative? My reasoning is: the caveats of container based building are completely integrated into the devs that know how containers works. Adding explanations in this project wiki would be like explaining how do You can assume that contributors that already understand how Docker works would be able to use the image as it is now. But, to ease its usage, we can just add the couple of commands needed to run the project scripts in a section under "Building" in the contribution notes. Think: Building
And in that third section add the neutral Docker form for the commands: What do you think? Podman and MacOS users already know they have to remove the user argument, but we can add a quick note for them. This change will live closer to the code and avoid drifting away if the wiki doesn't get updated. |
There was a problem hiding this comment.
Do you mind if I propose an alternative?
That sounds reasonable. Please:
- push changes for review
- simplify/normalise the nvim install
- consider latest debian
The container will be for local dev only:
- we use github actions for all of CI to install nvim, tools etc. in the default container
- CI actions / versions etc. are auto-updated via the dependabot agent. We don't want to add any manual tasks to update the dockerfile etc.
|
Sure, let me take a look and push a new commit with the changes. Installing custom software in /usr/local is a normal thing is Linux and is supported everywhere, but I can change it to use /usr as you said. The stylua shim is to avoid using cargo to install it. It needs to download half a Gb of packages from apt plus whatever stylua uses. I will review the base image. I just used trixie as an example because its what I use for my local system, but I expected to carefully review the Dockerfile if you were ok with adding it. |
Thank you. Cargo is definitely one to avoid for dev and CI.
Actually, I'm not too fussed about the location (see CI), just so long as we do it in the fewest possible commands and remember to set VIMRUNTIME. |
fjfnaranjo
left a comment
There was a problem hiding this comment.
PTAL @alex-courtis. I did a self review to add some notes.
| docker build -t nvim-web-devicons:latest . | ||
| docker run --rm -ti --user "`id -u`:`id -g`" -v "$(pwd):/host" -w /host nvim-web-devicons:latest make |
There was a problem hiding this comment.
Please, someone run this commands locally. I don't have docker to test them.
| @@ -0,0 +1,21 @@ | |||
| FROM debian:stable-slim | |||
There was a problem hiding this comment.
There is latest, but not latest-slim. latest seems to be interchangeable with stable in this case (and will update when a new stable is made available).
For consideration. Mentioned in #629 .
Built by chatgpt from the steps:
Verified running: