Closed jgonggrijp closed 1 year ago
Ah, almost forgot to ask. I initially using an image of Node.js version 12, because this is what runs on the production server, but the depenencies wouldn't install in that case. Do you know why that hasn't been an issue in deployment so far, @JeltevanBoheemen?
Merging after side channel agreement with @JeltevanBoheemen.
These changes enable development using Docker, eliminating the need to install particular versions of Python, Node.js, PostgreSQL, Elasticsearch, Blazegraph or RabbitMQ on the host machine.
Everything seems to work as it would with the original dockerless approach (at least the good parts). The migrations take effect, the landing page looks good and the tests that pass on develop also pass on this branch, though I have not checked whether Celery tasks execute correctly.
It may have been possible to make better technical choices; I'm open to suggestions for improvements. There are also some limitations/simplifications compared to the dockerless situation, which should be documented in the README.
Most of the pre-existing glue code in the root directory, including the scripts in the
package.json
, is superseded by thedocker-compose.yml
. Thebootstrap.py
is superseded by theDockerfile
s and the functionality that ships with the base images.I gratefully peeked at the hard work that @BeritJanssen already put into dockerizing I-analyzer.
The docker setup does not attempt to run the frontend tests in the shell using JSDOM. Instead, I extended the
watchNoTest
gulp task to build the test bundle so it can still run in the browser.Arguably, the JSDOM stuff does not add much value in the non-Docker situation, either. As an optional additional step, I could eliminate all the JSDOM-related logic from the gulpfile entirely, reducing the
watch
task to what is nowwatchNoTest
and unifying thedefault
anddocker
tasks.