-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Build assets in Docker container + use same container setup in CI #1312
Conversation
…es in preparation for python3
:not(kbd) > kbd, ^ Property "not" must be followed by a ':' in /project/src/sass/_theme_rst.sass (line 518, column 3) at /project/node_modules/webpack/lib/NormalModule.js:316:20 at /project/node_modules/loader-runner/lib/LoaderRunner.js:367:11 at /project/node_modules/loader-runner/lib/LoaderRunner.js:233:18 at context.callback (/project/node_modules/loader-runner/lib/LoaderRunner.js:111:13) at Object.callback (/project/node_modules/sass-loader/dist/index.js:89:7) at Object.done [as callback] (/project/node_modules/neo-async/async.js:8069:18) at options.error (/project/node_modules/node-sass/lib/index.js:294:32) @ multi ./src/theme.js ./src/sass/theme.sass theme[1] Child mini-css-extract-plugin node_modules/css-loader/dist/cjs.js!node_modules/sass-loader/dist/cjs.js??ref--5-2!src/sass/badge_only.sass: Entrypoint mini-css-extract-plugin = * [0] ./node_modules/css-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js??ref--5-2!./src/sass/badge_only.sass 4.69 KiB {0} [built] + 7 hidden modules Child mini-css-extract-plugin node_modules/css-loader/dist/cjs.js!node_modules/sass-loader/dist/cjs.js??ref--5-2!src/sass/theme.sass: Entrypoint mini-css-extract-plugin = * [0] ./node_modules/css-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js??ref--5-2!./src/sass/theme.sass 227 bytes {0} [built] [failed] [1 error] ERROR in ./src/sass/theme.sass (./node_modules/css-loader/dist/cjs.js!./node_modules/sass-loader/dist/cjs.js??ref--5-2!./src/sass/theme.sass) Module build failed (from ./node_modules/sass-loader/dist/cjs.js): :not(kbd) > kbd, ^ Property "not" must be followed by a ':' in /project/src/sass/_theme_rst.sass (line 518, column 3)
…t running the build
… we’re setting up an environment that is isolated from the CI (or primary) container, then using the remote host’s Docker Engine."
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 hesitate a bit about changing the development and packaging process this much. Is there a strong reason to switch CI and/or local builds to use Docker?
Are you hitting specific issues with local development otherwise? Perhaps it helps to raise those issues first, before changing things too much.
Generally speaking, giving contributors multiple conflicting paths for development is a bit confusing, so worth being careful here.
|
||
cd /project | ||
|
||
npm run build |
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.
You should be running npm run dev
for development, not npm run build
. build
is for building the minified JS/CSS files, where dev
runs Webpack development server and takes care of hot reload of the assets.
|
||
If you have Docker available on your platform, you can get started building CSS and JS artifacts a bit faster and won't have to worry about any of the setup spilling over into your general environment. | ||
|
||
When building with Docker, we create an image containing the build dependencies, such as `SASS`_ , `Wyrm` and `Webpack`_ in the anticipated versions. Some of these are quite outdated and therefore ideal to isolate a container. The image is tagged as ``sphinx_rtd_theme:latest``. |
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.
This is true without Docker as well, everything is installed via NPM. Just to be clear to the contributor, I think this should be removed.
When building with Docker, we create an image containing the build dependencies, such as `SASS`_ , `Wyrm` and `Webpack`_ in the anticipated versions. Some of these are quite outdated and therefore ideal to isolate a container. The image is tagged as ``sphinx_rtd_theme:latest``. |
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 the Node version and Python versions expected for the build environment weren't previously made explicit, this comment felt very spot on :) I would always advocate having a Dockerfile in order to manifest the build environment. Not trying to make it mandatory, though, that's why it's just an additional development suggestion.
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.
This seems like a change for the contributing doc instead. The docker environment isn't going to be any different than the current build environment.
|
||
$ make docker-images # Builds an updated version of the docker image | ||
$ make docker-run # Runs the docker environment and builds the assets. The container exits after completing the build. | ||
$ make docker-copy-assets # Copies out the assets from the most recent docker-run |
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.
This process doesn't quite feel ready for contributors, it's a bit more complicated than the normal development pattern. Is there a reason to not just mount this path as a volume?
@@ -0,0 +1,29 @@ | |||
FROM node:14-alpine | |||
FROM python:2-alpine |
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.
This should be Python 3, we don't want to support Python 2 anymore
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.
Please see #1311
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.
Yeah, I already commented there as well. Python 3 is supported currently, Python 2 is not required and might be documented as not support at all even.
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.
This is not true AFAICT. We are using a version of node-sass
that uses a version of node-gyp
that doesn't support Python 3. I finally hit the same issue in bourbon-neat
and gave up, since Wyrm didn't allow an upgrade. See #1311
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 theme has been building on Python 3 for some time. This PR has passing builds for all Pythons: #1316
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 haven't found an explanation for that TBH, but I'm sure it's good :) When I change the Dockerfile to use FROM python:3-alpine
, I start getting errors that I never resolved, but I really did try to do it without touching our node stack. The "internet" seems to have similar issues.
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.
Odd, the errors don't necessarily surprise me, but I certainly can't offer an explanation. node-gyp
apparently has python 3 support since 4.0.0 -- I hit this issue back in #771 -- #771 (comment)
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.
We figured this out, or at least it's a little more clear why building on python3 image is not working. Seems Alpine is somehow using Node 18 and also cannot find the /usr/bin/python3
binary (or Alpine's python package only installs a /usr/bin/python
binary
.circleci/config.yml
Outdated
- run: docker build -t sphinx_rtd_theme:latest . | ||
- run: docker run --cidfile=.container_id --mount type=bind,source="${CIRCLE_WORKING_DIRECTORY}/src",target=/project/src,readonly sphinx_rtd_theme:latest | ||
- run: docker cp "$(cat .container_id):/project/sphinx_rtd_theme" . | ||
- run: docker cp "$(cat .container_id):/project/package-lock.json" . |
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.
Noted already, but the node orb should be used here instead of Docker.
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.
This is now replaced with a CircleCI env that builds our Docker image like we specify and it doesn't take a lot of build time 👍
Also, I should note that I raised issues on this PR, but I think there are simpler alternatives to this and it is probably more helpful to discuss some build/development issues before going too much further. |
Build with Node 14 installed through orbs. Fixes readthedocs#1275
This introduced syntax errors that were not picked up in review, the `:not()` psuedo selector can't lead a selector in SASS.
d21b190
to
a9aff93
Compare
For the record: This approach worked fine and builds were ✔️. I'd like to contest that Dockerized build environments are the way forward 😉 |
From chat, I think this PR should still continue as an additional piece to local development. This seemed close, but using Python3 and Node 14 would be issues to resolve. I would still hold off on altering local development workflow or our CI builds though. Switching to Docker has side effects that require a bit more consideration, and we'd rather avoid disparate development workflows for now. |
Fixes #1310