Most importantly, in build-ui.bash, fix an extra "&&". This meant
that if the build command fails, it would proceed and cause confusion.
This happened for me: I ran it without the emulation installed. Both
the build-server and deploy stages had problems, but because of the "&&"
the deploy target didn't actually return failure. After I fixed the
emulation problem, there was a bad cached layer.
Also save the build output from the dev stage.
I'm tired of all the boilerplate, so use the new
GPL-3.0-linking-exception license identifier instead in all the server
components.
I left the ui stuff alone because I'm just going to replace it (#111).
Add a checker for the header because it's easy to forget.
This eases build setup. Where Yarn requires a separate package
repository, npm is available in the standard one.
yarn's package repository signature was recently expired, and apparently
will expire again in a year. Avoid dealing with that.
Fixes#110.
Besides being more clear about what belongs to which, this helps with
docker caching. The server and ui parts are only rebuilt when their
respective subdirectories change.
Extend this a bit further by making the webpack build not depend on
the target architecture. And adding cache dirs so parts of the server
and ui build process can be reused when layer-wide caching fails.
This replaces the previous Dockerfile, which was a single stage for
building and deployment.
The new one is a multi-stage build. Its "dev" target has the full
development environment; its "deploy" target is more slim. It supports
cross-compiled builds via BuildKit, eg to prepare a build suitable for
a Raspberry Pi:
docker buildx build --load --platform=linux/arm64/v8 --tag=moonfire-nvr --progress=plain --target=deploy -f docker/Dockerfile .
Coming next: updating the installation docs.
Scott Lamb