When reading the Meilisearch token from the file specified in the
configuration, we need to ensure any whitespace are trimmed from the
string. If the token file was created with a text editor, or even a
shell pipeline, it's likely to have a trailing newline character. If we
do not remove this, authenticated requests to Meilisearch will fail.
The `run-tests.sh` script sets up a full environment for the integration
tests. This includes starting Meilisearch (with a master key to enable
authentication) and generating an ephemeral JWT secret. After the tests
are run, the environment is cleaned up.
```sh
just test
just unit-tests
just integration-tests
```
Refactoring the code a bit here to make the `Rocket` instance available
to the integration tests. To do this, we have to convert to a library
crate (`lib.rs`) with an executable entry point (`main.rs`). This
allows the tests, which are separate crates, to import types and
functions from the library.
Besides splitting the `rocket` function into two parts (one in `lib.rs`
that creates the `Rocket<Build>` and another in `main.rs` that becomes
the process entry point), I have reworked the initialization process to
make better use of Rocket's "fairings" feature. We don't want to call
`process::exit()` in a test, so if there is a problem reading the
configuration or initializing the context, we need to report it to
Rocket instead.
We'll use a JWT in the `Authorization` request header to identify the
user saving a page. The token will need to be set in the _authorization
token_ field in the SingleFile configuration so it will be included when
uploading.
The default messages printed when the process panics because the
configuration could not be loaded or the application context could not
be initialized are somewhat difficult to read. Instead of calling
`unwrap` in these cases, we need to explicitly handle the errors and
print more appropriate messages.
