The frontend container already comes with a `node` user. In some instances, the new `dev` and old `node` user would have ID or name collisions. This PR fixes that by only reusing the `node` user.
With the proposed changes the time required to run `./bin/compose setup`
is being reduced from ~18 minutes down to ~7 minutes on my machine.
In addition a workaround is applied to reduce the size of the images.
== Changes
=== Speed-Up `bundle install`
The time spent withing `bundle install` takes a significant amount time
during the `./bin/compose setup`.
We could make use of two improvements, which both allows us to
utitlize multiple CPU cures:
* Make use of the bundle `--jobs` argument
* Make use of the lesser known/used `MAKE` environment variable
A significant amount of time spent during `bundle install` is actually
compiling C-extensions, that's why the usage of the `MAKE` variable will
drastically improve performence.
=== `useradd --no-log-init`
Unfortunately there is a nasty bug when running `useradd` for a huge
`uid`, which could result in excessive image sizes. See attached links
for more information.
=== BuildKit
BuildKit is the default builder toolkit for Docker on Windows and
DockerDesktop on Macs. Using BuildKit will greatly improve performance
when building docker images.
== Links
=== Speed-Up `bundle install`
* [One Weird Trick That Will Speed Up Your Bundle Install](https://build.betterup.com/one-weird-trick-that-will-speed-up-your-bundle-install/)
=== BuildKit
* [Build images with BuildKit](https://docs.docker.com/develop/develop-images/build_enhancements/)
* [Faster builds in Docker Compose 1.25.1 thanks to BuildKit Support](https://www.docker.com/blog/faster-builds-in-compose-thanks-to-buildkit-support/)
=== `useradd --no-log-init`
* Best practices for writing Dockerfiles: [User](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user)
* golang/co: [archive/tar: add support for writing tar containing sparse files](https://github.com/golang/go/issues/13548)
Fix various problems with the docker setup and frontend changes
* Set the node version to the same one that is used in the final packages and that is required in package.json
* Change the order of operations for backend container building
* Set the npm dependencies back to where they were
* Change browserslist rules for firefox
* Fix some docker commands for pullpreview
* Add b12f as a pullpreview admin
Co-authored-by: ulferts <jens.ulferts@googlemail.com>
* Move development docker-compose file to the main directory
This requires us to move some other files around, like the pullpreview and example docker-compose file for production
setups. This commit also does some housekeeping, like removing some old files and deduping configuration.
* Updated to selenium grid
* Fix in-Docker Selenium tests
The Selenium tests now run inside a Docker Chrome Container. Backwards compatability with non-docker setups is not
guaranteed, though it should not be hard to implement with a couple of small fixes.
* Updated docker development documentation
* Improved test timings, changed the documentation
* Updated docker testing again
* Run npm in the frontend directory
* Really run npm in the frontend directory
* Also run npm in frontend when setting up travis cache
* Change directory for one command only
* Change default test driver name
* CI test change fixes
* Fixed syntax error
* Added dev check
* Trying to fix firefox resizing
* Trying to get tests running
* Stop resizing firefox
* Fixed apple icon spec
* fix host in url helpers for omniauth spec
* Fix omniauth specs
* Fix docs
* Small fixes to docker tests
* Added package.json back in
* Change env variables
Co-authored-by: Markus Kahl <machisuji@gmail.com>
There are now separate containers for testing purposes, and the frontend container is a node-only image. Containers run
with a user that has the current user id and gid, making sure that any files that are installed by bundler or npm are
user-owned.
Selenium tests can be ran, but not all of them work yet.
Oliver Günther