- Updated the Github Actions to build just one binary with all DB
Backends.
- Created a hadolint workflow to check and verify Dockerfiles.
- Fixed current hadolint errors.
- Fixed a bug in the Dockerfile.j2 which prevented the correct libraries
and tools to be installed on the Alpine images.
- Deleted travis.yml since that is not used anymore
- Updated crates
- Updated rust-toolchain
- Updated Dockerfile to use latest rust 1.48 version
- Updated AMD64 Alpine to use same version as rust-toolchain and support
PostgreSQL.
- Updated Rocket to the commit right before they updated hyper.
Until that update there were some crates updated and some small fixes.
After that build fails and we probably need to make some changes
(which is probably something already done in the async branch)
The runtime image was using a very old Alpine version.
This caused issues with the catatonit install
Now using the Balena armv7hf Alpine image for this.
With some apt/dpkg magic building multidb containers for arm versions
now also works. As long as the build stage and docker-image stage use
the same base (debian buster now) it should all work.
Resolves#530, resolves#1066
This is useful for making local customizations upon container start. To use
this feature, mount a script into the container as `/etc/bitwarden_rs.sh`
and/or a directory of scripts as `/etc/bitwarden_rs.d`. In the latter case,
only files with an `.sh` extension are sourced, so files with other
extensions (e.g., data/config files) can reside in the same dir.
Note that the init scripts are run each time the container starts (not just
the first time), so these scripts should be idempotent.
* Switch healthcheck interval/timeout from 30s/3s to 60s/10s.
30s interval is arguably overkill, and 3s timeout is definitely too short
for lower end machines.
* Use HEALTHCHECK CMD exec form to avoid superfluous `sh` invocations.
* Add `--silent --show-error` flags to curl call to avoid progress meter being
shown in healthcheck logs.
The muslrust images seem to have a workdir of /volume as opposed to / in the
others so doing cargo new like this would create the folder in /volume/app.
No need to use two different base images. Debian buster is pulled later
anyway so we can just use it for the vault stage as well.
My reason for this change is partly to avoid redundancy and partly to
make it easier to build everything yourself. When all the build
environment is based on Debian than you just have to figure out how to
build a Debian Docker base image (ref:
https://github.com/ypid/docker-makefile).