Iain Sproat
96bed71022
* Improves error logging
- use pino error logger correctly by passing in error as first argument
* monitor deployment: Filter logging at INFO level and above
* Use structured logging to create parameters for monitoring results
* Add structured logging to obj fileimport service
* Fileimport service, fix and improve logging
- use child logger with additional context where possible
- select appropriate logging level
- fix duplicated context in log statement
* REST endpoints, add context to structured logging and remove same context from message
* Webhook service provides context to bound logger to properly use structured logging
- Pass bound logger containing context to `makeNetworkRequest`
- do not log url, as it may contain a secret (like Discord's webhook urls), instead log the webhook Id
- log error message when network call fails
* upload: make better use of structured logging when recording data
* pino-pretty when in dev or test mode
- pino-pretty configured to send to stderr
* LOG_PRETTY env var
* Silence structured logging during testing
- can not rely on determining the port number by reading from stdout/stderr
- instead we determine which port is free, then create our server on that port
- we then poll that port until the server is ready before commencing tests
* Allow puppeteer to install chromium
* Do not need to install chromium separately
Using CLI
You can run it like so from the server package's root directory: ./bin/cli
Use the --help argument to get more info about each command.
Example for running migrations: ./bin/cli db migrate latest
Creating new commands
CLI is defined using yargs.We use it to define hierarchical trees of commands which allows for better organization both for command definition and for using the CLI.
All commands are created in the commands directory. Commands should be defined using command modules.
Any top-level modules under commands will be assumed to be command modules. If you want to define a child command for a top-level command, then configure the top-level command to look for further child commands using .commandDir().
Then put those child command modules in a subdirectory that is named after the top level command. So if the top level command is "db", then all of its child commands should be put inside a "db" subfolder.
Example commands dir:
- commands
- db
- migrate.js
- db.js
In this case, db.js is the command module for the top-level db command. And then inside the db folder there's a command module migrate.js for the migrate child command of db.
This results in 2 commands - db and db migrate.