The build pipeline in its current state is a good start but there is much more that can be done to improve and streamline the build process.

For example with the addition of cross each build can take upwards of 20 minutes to complete. This is without the additional overhead of multiple release targets. It is possible to limit which files can trigger a build but it is unclear as to what this means for pull requests that require certain build jobs to complete before merging. It is also unclear as to whether this can be done on a per-job basis without a custom script to do so.

Before any further work can be done on this issue some further investigation is required.

• Investigate splitting the pipeline to separate rust and docker jobs
• Investigate the use of cargo-audit to check for security vulnerabilities
• Investigate the use of cargo-suity for test result reporting
• Investigate the use of tarpaulin to check code coverage
• Investigate alternatives to cross for faster builds

Currently the project only supports logging to stderr. Replace the use of env_logger with a custom solution that supports logging to various different outputs for each of the different component systems. Basic support should be provided for stdout, stderr and the file system. Extended support would allow logging to external systems and JSON endpoints.

Each component system should be able to be configured separately to point to a different output. For example web requests could be logged to Azure Monitor and scheduled tasks could be logged to stdout.

Currently the command-line interface supports static configuration for the built-in web server via the host and port arguments. These map to the configurable host and port configuration options that can be specified in the configuration file.

Rather than manually adding a static argument for each configurable option it would be beneficial to dynamically generate the options from the configuration structs. It appears that something akin to structopt may be the best way to implement this. The solution would ideally use the dot notation to specify sub-options.

For example to change the logging level for the web server it could be possible to use the command brace web run --web.log.level warn without having to manually implement a new argument for that specific option.

Greetings, and apologies in advance for the random ping 😄

I noticed you were using rusty-hook through a GH search and just wanted to share that we've published a new version of rusty-hook (0.5.1). This version enables automatically adding all the git hooks on build which eliminates the need to manually run the init command.

With this new version, rusty-hook can simply be added as a dev-dependency

[dev-dependencies]
rusty-hook = "0.5.1"

There's still a need to do a one-time cargo install rusty-hook on the system, but hopefully cargo will add support to make dev-deps runnable in the future and we can remove that one time install step too.

Thanks for giving rusty-hook a try, and if you have any feedback/suggestions/complaints/etc. please let us know!

Currently the project only supports a single release target of x86_64-unknown-linux-musl. This target is ideal for producing a statically-linked binary that can be used inside of a lightweight alpine linux container. However there really needs to be support for additional targets.

At a minimum we should cover different architectures for linux with gnu and musl variants where appropriate. In the long term we should provide releases for macOS and Windows too.

Currently there is only support for configuration defined in TOML files. With the use of serde powering the serialization and deserialization of configuration it should be trivial to add additional format support.

Add a new CLI command to allow for programatically editing the configuration options of a given site without having to write to the configuration file. A good example of this is the git config command that allows getting and setting configuration of a local git repository.