Created shell devcontainer for a reproducable build environment #847
Conversation
There was a problem hiding this comment.
Hi, thanks for the contribution. I am a little hesitant on this as I am not too into the devcontainers thing.
While I personally likes to work on my host environment I can understand alternative opinions, this is not a blocking issue. Just want to hear about the intended goal.
Can you tell me the primary frustration/friction you want to solve here? Is it the dev environment setup being not intuitive to setup, or the build themselves are not reproducible？
.devcontainer/config-environment.sh
Outdated
|
|
||
| make download-tools | ||
| go get | ||
| yarn |
There was a problem hiding this comment.
doesn't seem right, it should be only one yarn
There was a problem hiding this comment.
There are additional go dependencies that are downloaded during a go run/build that aren't downloaded by make download-tools, so this pre-caches them.
There was a problem hiding this comment.
I see what you mean. Only the yarn inside the ui directory is needed. I'll fix that.
.devcontainer/Dockerfile
Outdated
| @@ -0,0 +1,3 @@ | |||
| FROM mcr.microsoft.com/devcontainers/typescript-node:1-22-bookworm | |||
|
|
|||
| RUN apt update No newline at end of file | |||
There was a problem hiding this comment.
Is this the standard way to do this? This packages a layer of "latest" (build time) package list, can't the user just run this themselves if they want extra packages?
There was a problem hiding this comment.
I don't think it's non-standard, just different. I had changed it from the default in the devcontainer.json because I thought there might be other stuff that needed to be added on top of the base image, but that ended up not being the case. I'll change this back.
.devcontainer/config-environment.sh
Outdated
|
|
||
| cd ui | ||
| yarn | ||
| yarn build No newline at end of file |
There was a problem hiding this comment.
AFAIK you should not try to build the actual code in environment setup (it seems like the template you are using also says use this to "download required toolchains"), as that can cause breakage if the code stops building.
There was a problem hiding this comment.
The base template didn't include any of this, I wrote all this myself. Technically this all happens after the container image is built as a post-build action.
.devcontainer/devcontainer.json
Outdated
| // "customizations": {}, | ||
|
|
||
| // Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root. | ||
| //root needed because server runs on port 80 and `yarn build` fails without it |
There was a problem hiding this comment.
Can you just set GOTIFY_SERVER_PORT environment variable instead of running as root?
There was a problem hiding this comment.
Perhaps, honestly didn't try that. Will test it out.
There was a problem hiding this comment.
yarn build still fails though without root, not sure how critical this error is, I'm not a node person myself
node ➜ /workspaces/server/ui (master) $ yarn build
yarn run v1.22.22
$ tsc
$ vite build
vite v7.0.6 building for production...
✓ 12120 modules transformed.
✗ Build failed in 13.74s
error during build:
EACCES: permission denied, unlink '/workspaces/server/ui/build/static/PluginDetailView-Dsl1DMbT.js'
at unlinkSync (node:fs:1953:11)
at _unlinkSync (node:internal/fs/rimraf:215:14)
at rimrafSync (node:internal/fs/rimraf:196:7)
at node:internal/fs/rimraf:254:9
at Array.forEach (<anonymous>)
at _rmdirSync (node:internal/fs/rimraf:251:7)
at rimrafSync (node:internal/fs/rimraf:194:7)
at Object.rmSync (node:fs:1248:10)
at emptyDir (file:///workspaces/server/ui/node_modules/vite/dist/node/chunks/dep-BHkUv4Z8.js:2516:11)
at prepareOutDir (file:///workspaces/server/ui/node_modules/vite/dist/node/chunks/dep-BHkUv4Z8.js:34153:4)
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
While attempting to help close issue #845 that I opened, I found myself unable to build the docker images or even the binary in many different environments. I'm not a developer by trade, so I felt that a reproducible dev environment was something that was within my capabilities to contribute to the project. If it is not something needed or wanted by the core development team, then feel free to reject it. It will not hurt my feelings. |
|
Does this devcontainer have to be microsoft's ? Can we use docker.io/gotify/build (and just install dev tools on top of it?) Feels more reproducible if that is the goal |
|
I don't see why not. I can certainly implement that and test it out. |
|
Updated to the gotify build base image. Had to implement a Dockerfile to install npm/yarn. |
|
Don't merge this yet. I'm still working through some Dev Container-ism to try and get everything running smoothly. |
|
Yea I think this needs some thinking though, we kind of already roll our own "dev container" in Makefile, our official build commands are already through Docker. So if we just naively do a wrapper it is just docker in docker. I wish there can be at least a plan forward where eventually we converge into one way of doing "reproducibility" |
|
Well I'm going to keep poking at this and maybe come up with something the main devs will like. Either way, it'll be a good learning experience for me. |
2 participants
The intent (hope) is to have a reproducible build environment for the server so that there's consistent results.