-
-
Notifications
You must be signed in to change notification settings - Fork 724
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docker based build #4415
docker based build #4415
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #4415 +/- ##
=======================================
Coverage 87.57% 87.58%
=======================================
Files 246 246
Lines 33396 33396
Branches 2223 2198 -25
=======================================
+ Hits 29247 29249 +2
- Misses 3130 3138 +8
+ Partials 1019 1009 -10 ☔ View full report in Codecov by Sentry. |
Can this run the browser tests? I had some trouble with that on an M1 Mac. |
@@ -0,0 +1,15 @@ | |||
services: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does a docker-compose really make sense with only one service?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would reccomnd to add an entrypoint to the docker file by using npm run start
and export 9966
port.
Also add some explanation to the CONTRIBUTING.md
file on how to use this image.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does a docker-compose really make sense with only one service?
I already imagine at least 1 or 2 other services (so I start by a first):
- a headless web browser for testing purposes
- a web server to mak run a release with some examples
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still don't see a huge value here...
You can simply mount the entire cloned repo instead of a selective number of folders.
You can switch the entry point command to run different scripts from the package.json file.
Bottom line, this can be dramatically simplified.
Dockerfile
Outdated
|
||
RUN echo "hello world" | ||
|
||
RUN apt-get update && apt-get install -y \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The .devcontainer
should probably use the Dockerfile, otherwise this is duplicated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this docker container is published, so I'm not sure .devcontainer can use this docker.
I would reccoment trying to find a container that already has most of these installed and simply use it instead of installing everything.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would reccoment trying to find a container that already has most of these installed and simply use it instead of installing everything.
I'm sure to get this specific point. Are you talking about .devcontainer
stuff ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, good point.
I did not consider to integrate docker facilities so far away, I just though about not having to change my environment (installing node and dependencies).
So, I do not aim to manage .devcontainer in that specific P.R.
Is it something mandatory here ?
Dockerfile
Outdated
xvfb \ | ||
&& rm -rf /var/lib/apt/lists/* | ||
|
||
RUN apt-get update && apt-get install -y \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this split into two lines? Why not installing everything at one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this split into two lines? Why not installing everything at one?
Well, I'm just following documentation from CONTRIBUTING.md : https://github.com/maplibre/maplibre-gl-js/blob/main/CONTRIBUTING.md#linux-and-by-extension-github-codespaces
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably a mistake there too, or done with readability in mind.
We should aim at reducing docker layers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, it will be done today.
Good question. |
Checkout the CI code, it has most of what the CI is running, which is stuff in most cases you should run locally to make sure the PR checks pass. |
71edd03
to
5915500
Compare
Only |
Not sure what you mean by another step, but if the docker image is not good at the moment, I suggest to fix it before merging it, otherwise it misses the point a bit... |
I"ll do my best. github CI is not a part I know well. It seems to be github specific, as I though to suggest something more independent, not linked to github CI. |
It might be interesting to publish this dev container to ghcr for every push to main so that people won't need to build it locally... |
OK. |
.devcontainer/Dockerfile
Outdated
|
||
RUN \ | ||
# Configure global npm install location, use group to adapt to UID/GID changes | ||
if ! cat /etc/group | grep -e "^npm:" > /dev/null 2>&1; then groupadd -r npm; fi \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not use a node docker image as a base image instead of all this complexity?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. fixed.
.devcontainer/Dockerfile
Outdated
&& chmod g+s ${NPM_GLOBAL} \ | ||
&& npm config -g set prefix ${NPM_GLOBAL} \ | ||
&& su ${USERNAME} -c "npm config -g set prefix ${NPM_GLOBAL}" \ | ||
# Install eslint |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure why you would need to install eslint globally, it is installed locally as part of npm ci command.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, fixed.
@@ -1,4 +1,5 @@ | |||
{ | |||
"name": "MapLibre container using node.js", | |||
"build": { "dockerfile": "Dockerfile" }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would assume that using a docker image would avoid the need for all the below installations.
Also, if we publish an image as part of the commits to main I would expect to be able to use this image for codespaces...?
.github/workflows/release.yml
Outdated
@@ -6,6 +6,26 @@ on: | |||
workflow_dispatch: | |||
|
|||
jobs: | |||
push-store-image: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
push-store-image: | |
push-dev-image: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, applied.
working-directory: './devcontainer' | ||
steps: | ||
- name: 'Checkout GitHub Action' | ||
uses: actions/checkout@main |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better to use a version, like in other places in the CI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better to use a version, like in other places in the CI.
OK. So I used this:
ghcr.io/maplibre/maplibre-gl-js:${{ steps.package-version.outputs.current-version }}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant v4 or so for the checkout action...
.devcontainer/Dockerfile
Outdated
libgif-dev \ | ||
&& rm -rf /var/lib/apt/lists/* | ||
|
||
CMD npm ci && npm run start |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add npm run build-dist here.
npm run start should be the entry point to allow replacing it with other commands.
This will allow for better ergonomics and avoid the need for docker compose.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, done
A clarification point: what is expected for CI ?
|
CI should stay the same, besides pushing an image for every commit to main. |
I'll work on that way. However, in term of use cases, here is what I have in mind:
=> So I would suggest not to include source code inside provided docker image
What do you think ? |
I don't think it will change the size dramatically, so the argument is weak. We can always remove it later on, I suggest to include it, see how it feels and then see if we truly need to optimize it. |
F.Y.I.: For testing purpose, I realize that google-chrome must be installed. |
@@ -0,0 +1,38 @@ | |||
ARG VARIANT=20-bookworm-slim |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we are using puppeteer for e2e tests I would recommend a base image that already has chrome and node like:
https://pptr.dev/guides/docker
And avoid all these complexity of installing chrome etc.
I would consider starting from the following docker image and see if there are missing stuff that needs to be added instead of bootstrapping an image: |
This looks stale. |
docker compose build
command.docker compose up
Fixes #57