The initial docker builds takes a while with QEMU, while the built
docker image caches makes building locally very fast. If this is
for the purpose of reuse, one may just pull the latest version
from the docker registry, making it more efficient than just
building from the sources (without having experience with rust/cargo).
Docker builds can be performed as follows:
$ docker buildx build --platform linux/amd64 -t marcellodesales/mdbook -o type=docker .
[+] Building 2.8s (23/23) FINISHED
=> [internal] load build definition from Dockerfile 0.0s
=> => transferring dockerfile: 2.17kB 0.0s
=> [internal] load .dockerignore 0.0s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for docker.io/library/alpine:3.16.0 2.0s
=> [internal] load metadata for docker.io/rustlang/rust:nightly-buster-slim 1.4s
=> [auth] library/alpine:pull token for registry-1.docker.io 0.0s
=> [auth] rustlang/rust:pull token for registry-1.docker.io 0.0s
=> [runtime 1/3] FROM docker.io/library/alpine:3.16.0@sha256:686d8c9dfa6f3ccfc8230bc3178d23f84eeaf7e457f36f271ab1acc53015037c 0.0s
=> => resolve docker.io/library/alpine:3.16.0@sha256:686d8c9dfa6f3ccfc8230bc3178d23f84eeaf7e457f36f271ab1acc53015037c 0.0s
=> [builder 1/11] FROM docker.io/rustlang/rust:nightly-buster-slim@sha256:609c65daad3c69f9a37717e45d794e2eab99ad488dc5d492b8fc85c97c1df531 0.0s
=> => resolve docker.io/rustlang/rust:nightly-buster-slim@sha256:609c65daad3c69f9a37717e45d794e2eab99ad488dc5d492b8fc85c97c1df531 0.0s
=> [internal] load build context 0.0s
=> => transferring context: 4.94kB 0.0s
=> CACHED [builder 2/11] RUN apt-get update && apt-get install -y git 0.0s
=> CACHED [builder 3/11] WORKDIR /usr/src/github.com/rust-lang 0.0s
=> CACHED [builder 4/11] RUN USER=root cargo new mdBook 0.0s
=> CACHED [builder 5/11] COPY Cargo.toml Cargo.lock /usr/src/github.com/rust-lang/mdBook 0.0s
=> CACHED [builder 6/11] COPY examples /usr/src/github.com/rust-lang/mdBook/examples 0.0s
=> CACHED [builder 7/11] WORKDIR /usr/src/github.com/rust-lang/mdBook 0.0s
=> CACHED [builder 8/11] RUN rustup target add x86_64-unknown-linux-musl 0.0s
=> CACHED [builder 9/11] RUN cargo build -vv --config "net.git-fetch-with-cli=true" --target x86_64-unknown-linux-musl --release 0.0s
=> CACHED [builder 10/11] COPY src /usr/src/github.com/rust-lang/mdBook/src 0.0s
=> CACHED [builder 11/11] RUN cargo build --locked --bin mdbook --release --target x86_64-unknown-linux-musl 0.0s
=> CACHED [runtime 2/3] COPY --from=builder /usr/src/github.com/rust-lang/mdBook/target/x86_64-unknown-linux-musl/release/mdbook /usr/local/bin/mdbook 0.0s
=> CACHED [runtime 3/3] RUN echo "I am running on linux/arm64, building for linux/amd64" > /etc/build.log 0.0s
=> exporting to oci image format 0.7s
=> => exporting layers 0.0s
=> => exporting manifest sha256:f658cf0db29cb5655960164f745fbd841fb0dbba53f2b387e60c5e23f360459b 0.0s
=> => exporting config sha256:55c34204ee9e1fea12a11af808615f46f89cb428a3c6ff1e46c1bade9282a26a 0.0s
=> => sending tarball 0.7s
=> importing to docker
Running the server is a matter of the following:
* Specifying a container to run exposing a given port number
* Specifying the source-code to load mounted as docker volume
At this point, just specifying the current dir of sources with md files
and the local port number the same as the server, here's what we have:
$ ls -la src
total 24
drwxr-xr-x 13 mdesales staff 416 Feb 22 14:06 .
drwxr-xr-x 12 mdesales staff 384 Feb 22 14:06 ..
-rw-r--r-- 1 mdesales staff 980 Feb 22 14:06 README.md
-rw-r--r-- 1 mdesales staff 4764 Feb 22 14:06 SUMMARY.md
drwxr-xr-x 10 mdesales staff 320 Feb 22 14:06 assets
drwxr-xr-x 7 mdesales staff 224 Feb 22 14:06 data
drwxr-xr-x 19 mdesales staff 608 Feb 22 14:06 infra
drwxr-xr-x 7 mdesales staff 224 Feb 22 14:06 monitoring
drwxr-xr-x 7 mdesales staff 224 Feb 22 14:06 onboard
drwxr-xr-x 17 mdesales staff 544 Feb 22 14:06 services
drwxr-xr-x 4 mdesales staff 128 Feb 22 14:06 structure
drwxr-xr-x 43 mdesales staff 1376 Feb 22 14:06 support
drwxr-xr-x 17 mdesales staff 544 Feb 22 14:06 tips
$ docker run -ti -v $(pwd)/src:/src -p 3000:3000 marcellodesales/mdbook
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
2023-02-23 03:08:29 [INFO] (mdbook::book): Book building has started
2023-02-23 03:08:29 [INFO] (mdbook::book): Running the html backend
2023-02-23 03:08:34 [INFO] (mdbook::cmd::serve): Serving on: http://0.0.0.0:3000
2023-02-23 03:08:34 [INFO] (warp::server): Server::run; addr=0.0.0.0:3000
2023-02-23 03:08:34 [INFO] (warp::server): listening on http://0.0.0.0:3000
2023-02-23 03:08:34 [INFO] (mdbook::cmd::watch): Listening for changes...
At this point, one may just check the service locally as follows:
$ curl -I http://localhost:3000/
HTTP/1.1 200 OK
content-length: 26343
content-type: text/html
accept-ranges: bytes
last-modified: Thu, 23 Feb 2023 03:08:29 GMT
date: Thu, 23 Feb 2023 03:08:35 GMT
$ curl http://localhost:3000/ | grep mdBook
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 <!-- Book generated using mdBook -->
100 26343 100 26343 0 0 366k 0 --:--:-- --:--:-- --:--:-- 467k
The code here leads me to believe that the intention is for the sidebar
to be default visible on large screens (where `clientWidth` > 1080) and
hidden otherwise.
However, as previously written, if the `localStorage.getItem` call fails
(for example, if the user agent is not accepting cookies), then we fall
back to `sidebar = sidebar || 'visible';` — but `sidebar` is already set
to `hidden`, so the `|| 'visible'` never happens.
This results in the sidebar hiding itself on every navigation through an
mdBook, meaning if you're just switching between sections trying to find
something that you keep needing to re-open the sidebar.
It is preferable to remove WebKit-specific styling and use the browser
and OS default scrollbars.
Thanks to comments from @julianfortune, @arniu, and @ehuss.
Closes#1483.