Fix docs/website/ code formatting

By running `make format`

Author: dlachaume

docs/website/adr/001-use-adr.md

@@ -3,7 +3,7 @@ slug: 1
 title: |
   1. Record Architecture Decisions
 authors:
-- name: Mithril Team
+  - name: Mithril Team
 tags: [Accepted]
 date: 2022-04-21
 ---
@@ -22,10 +22,10 @@ easily.
 
 ## Decision
 
-* We will use _Architecture Decision Records_, as described by Michael Nygard in
+- We will use _Architecture Decision Records_, as described by Michael Nygard in
   this
   [article](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions).
-* We will follow the convention of storing those ADRs as Markdown formatted
+- We will follow the convention of storing those ADRs as Markdown formatted
   documents stored under `docs/adr` directory, as exemplified in Nat Pryce's
   [adr-tools](https://github.com/npryce/adr-tools). This does not imply we will
   be using `adr-tools` itself.

docs/website/adr/002-use-structured-logging.md

@@ -3,7 +3,7 @@ slug: 2
 title: |
   2. Use simple structured logging
 authors:
-- name: Mithril Team
+  - name: Mithril Team
 tags: [Superseded]
 date: 2022-04-24
 ---
@@ -14,18 +14,18 @@ Superseded by [ADR 7](/adr/7)
 
 ## Context
 
-* Logs are a critical tool for operating any software system, enabling [observability](https://cloud.google.com/architecture/devops/devops-measurement-monitoring-and-observability) of the system.
-* Following [12 Factor Apps](https://12factor.net/logs) principles, providing the needed components and tools to be able to configure logging and monitoring should not be the responsibility of the software components
+- Logs are a critical tool for operating any software system, enabling [observability](https://cloud.google.com/architecture/devops/devops-measurement-monitoring-and-observability) of the system.
+- Following [12 Factor Apps](https://12factor.net/logs) principles, providing the needed components and tools to be able to configure logging and monitoring should not be the responsibility of the software components
 
 ## Decision
 
 _Therefore_
 
-* Each component of the system use [Structured logging](https://www.sumologic.com/glossary/structured-logging/) using documented and standardised JSON format for its logs
-* Logs are always emitted to `stdout` of the process the component is part of
+- Each component of the system use [Structured logging](https://www.sumologic.com/glossary/structured-logging/) using documented and standardised JSON format for its logs
+- Logs are always emitted to `stdout` of the process the component is part of
 
 ## Consequences
 
-* The schema of the logged items should be properly documented in a JSON schema
-* It is the responsibility of the node operator to consume the logs and process them
-* We use existing libraries to provide needed log infrastructure, like [slog](https://zsiciarz.github.io/24daysofrust/book/vol2/day4.html) for Rust
+- The schema of the logged items should be properly documented in a JSON schema
+- It is the responsibility of the node operator to consume the logs and process them
+- We use existing libraries to provide needed log infrastructure, like [slog](https://zsiciarz.github.io/24daysofrust/book/vol2/day4.html) for Rust

docs/website/adr/003-release/index.md

@@ -3,7 +3,7 @@ slug: 3
 title: |
   3. Release process and versioning
 authors:
-- name: Mithril Team
+  - name: Mithril Team
 tags: [Accepted]
 date: 2022-10-21
 ---
@@ -14,32 +14,31 @@ Accepted
 
 ## Context
 
-In order to deliver regularly the software to our users, we should implement a release process based on a predictable versioning scheme. 
+In order to deliver regularly the software to our users, we should implement a release process based on a predictable versioning scheme.
 
 ### Versioning
 
 A Release Version determines a distribution of determined node versions and underlying libraries.
 
- * Our softwares must be able to interact seamlessly with other Mithril software.
- * Our softwares must be able to be hosted on crates.io.
- * Our softwares must clearly indicate compatibility with other Mithril components to end users.
- 
+- Our softwares must be able to interact seamlessly with other Mithril software.
+- Our softwares must be able to be hosted on crates.io.
+- Our softwares must clearly indicate compatibility with other Mithril components to end users.
 
 ### Release process
 
 A Release is a software package that is built once and then promoted from the testing environment to the production environment. It can be signed.
 
- * Keep it simple.
- * Automated as much as possible: all points not requiring human decision shall be automated.
- * Minimize the mean time to release.
+- Keep it simple.
+- Automated as much as possible: all points not requiring human decision shall be automated.
+- Minimize the mean time to release.
 
 ## Decision
 
 There are 3 versioned layers in the Mithril stack:
 
- * HTTP API protocol to ensure compatibility in the communication between nodes (use Semver).
- * Crate version: each node & library has its own version (use Semver). The commit digest is automatically added to the version by the CI pipeline.
- * Release Version: the distribution version (use version scheme **YYWW.patch** | **YYWW.patch-name**). The VERSION file is computed by the pipeline from the tag release.
+- HTTP API protocol to ensure compatibility in the communication between nodes (use Semver).
+- Crate version: each node & library has its own version (use Semver). The commit digest is automatically added to the version by the CI pipeline.
+- Release Version: the distribution version (use version scheme **YYWW.patch** | **YYWW.patch-name**). The VERSION file is computed by the pipeline from the tag release.
 
 The documentation is tied to a Release Version.
 
@@ -63,9 +62,11 @@ Starting just after a new release has been made:
 [![Release Process](./img/release_process.jpg)](./img/release_process.jpg)
 
 ### Hotfix Release
+
 ​
 In case of a blocking issue (following a distribution release) on the release environment that requires an immediate fix:
 ​
+
 1. Create a branch on the last release tag with the following scheme: `hotfix/{last_distribution-version}.{last_patch_number + 1}`.
 1. Development of the fix is done on this branch.
 1. After each commit on this branch, the CI creates an `unstable` tag & release which is not deployed on testing environment (testing must be done on an ad hoc environment manually created).
@@ -74,4 +75,3 @@ In case of a blocking issue (following a distribution release) on the release en
 1. In the release GitHub interface, edit the newly generated release, uncheck the `This is a pre-release` checkbox.
 1. The CI gets the built artifacts associated with this commit and generates a named release which is deployed on `release`.
 1. Merge the hotfix branch on main branch (and adapt the changes if they are not compatible with the current main branch).
-

docs/website/adr/004-mithril-network-update-strategy.md

@@ -3,7 +3,7 @@ slug: 4
 title: |
   4. Mithril Network Upgrade Strategy
 authors:
-- name: Mithril Team
+  - name: Mithril Team
 tags: [Accepted]
 date: 2023-01-05
 ---
@@ -20,9 +20,9 @@ We need to be able to keep enough of signer nodes and the aggregator able to wor
 
 Examples of such changes:
 
- * change in the message structure
- * change in the cryptographic algorithm
- * change in communication channels
+- change in the message structure
+- change in the cryptographic algorithm
+- change in communication channels
 
 ## Decision
 
@@ -43,8 +43,9 @@ This configuration works in the case where there is a centralized Aggregator Nod
 ### Era Activation Marker
 
 An Era Activation Marker is an information shared among all the nodes. For every upgrade, there are two phases:
- * a first marker is set on the blockchain that just indicates a new Era will start soon and softwares shall be updated.
- * a second marker is set that specifies the Epoch when they must switch from old to new behavior.
+
+- a first marker is set on the blockchain that just indicates a new Era will start soon and softwares shall be updated.
+- a second marker is set that specifies the Epoch when they must switch from old to new behavior.
 
 Every Era Activation Marker will be a transaction in the Cardano blockchain. This implies the nodes must be able to read transactions of the blockchain. Era Activation Markers can be of the same type, the first maker does not hold any Epoch information whereas the second does.
 

docs/website/adr/005-use-rfc3339-for-dates.md

@@ -1,9 +1,9 @@
 ---
 slug: 5
 title: |
-  5. Use rfc3339 for date formatting 
+  5. Use rfc3339 for date formatting
 authors:
-- name: Mithril Team
+  - name: Mithril Team
 tags: [Accepted]
 date: 2023-06-21
 ---
@@ -19,12 +19,14 @@ multiple formats being used.
 
 For example when querying a certificate from an aggregator, the `initiated_at` field did not specify the timezone,
 timezone that could be found in the `sealed_at` field:
+
 ```json
 {
   "initiated_at": "2023-05-26T00:02:23",
   "sealed_at": "2023-05-26T00:03:23.998753492Z"
 }
 ```
+
 Same problem in our databases where a date could be stored without timezone and milliseconds (ie: `2023-06-13 16:35:28`)
 in one table column and with them in another (ie: `2023-06-13T16:35:28.143292875Z`).
 
@@ -36,13 +38,13 @@ client can convert such date to their local time if needed.
 
 _Therefore_
 
-* We commit to use **RFC 3339** compatible date and time whenever we need to store or show a date and time.
+- We commit to use **RFC 3339** compatible date and time whenever we need to store or show a date and time.
 
 ## Consequences
 
-* All dates and time must use a dedicated type in the application, ie: the `DateTime<Utc>` type from
-[chrono](https://crates.io/crates/chrono) crate.
-  * This means that dates must **never** be stored in our types using Strings.
-* Internally, we will always use the **UTC timezone**, to avoid useless conversions between timezones.
-* Users or scripts querying dates from our applications or from our databases will be able to parse all of them using
-the same format.
+- All dates and time must use a dedicated type in the application, ie: the `DateTime<Utc>` type from
+  [chrono](https://crates.io/crates/chrono) crate.
+  - This means that dates must **never** be stored in our types using Strings.
+- Internally, we will always use the **UTC timezone**, to avoid useless conversions between timezones.
+- Users or scripts querying dates from our applications or from our databases will be able to parse all of them using
+  the same format.

docs/website/adr/006-errors-implementation.md

@@ -3,7 +3,7 @@ slug: 6
 title: |
   6. Errors implementation Standard
 authors:
-- name: Mithril Team
+  - name: Mithril Team
 tags: [Accepted]
 date: 2023-09-27
 ---
@@ -15,22 +15,23 @@ Accepted
 ## Context
 
 Error handling is difficult with Rust:
+
 - Many ways of implementing them with different crates ([`thiserror`](https://crates.io/crates/thiserror), [`anyhow`](https://crates.io/crates/anyhow), ...)
 - No exception like handling of errors
 - No stack trace or context available by default
 - Backtrace uniquely when a panic occurs and if `RUST_BACKTRACE` environment variable is set to `1` or `full`
 
-We think the errors handling should be done in a consistent way in the project. 
+We think the errors handling should be done in a consistent way in the project.
 Thus we have worked on a standardization of their implementation and tried to apply it to the whole repository.
 This has enabled us to have a clear vision of the do and don't that we intend to summarize in this ADR.
 
 ## Decision
 
 _Therefore_
 
-* We have decided to use `thiserror` and `anyhow` crates to implement the errors:
-  * [`thiserror`](https://crates.io/crates/thiserror) is used to create module or domain errors that come from our developments and can be easily identified (as they are strongly typed).
-  * [`anyhow`](https://crates.io/crates/anyhow) is used to add a context to an error triggered by a sub-system. The context is a convenient way to get 'stack trace' like debug information.
+- We have decided to use `thiserror` and `anyhow` crates to implement the errors:
+  - [`thiserror`](https://crates.io/crates/thiserror) is used to create module or domain errors that come from our developments and can be easily identified (as they are strongly typed).
+  - [`anyhow`](https://crates.io/crates/anyhow) is used to add a context to an error triggered by a sub-system. The context is a convenient way to get 'stack trace' like debug information.
 
 Here is a [Rust playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=bf667c443696beb90106f6ae627a57b9) that summarizes the usage of `thiserror`:
 
@@ -179,7 +180,7 @@ Caused by:
 Anyhow error: context
 ```
 
-Here is a [Rust playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=90f962ab001d2ea0321fc5da0d4ec0f1) that summarizes the usage of the `context` feature form `anyhow`: 
+Here is a [Rust playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=90f962ab001d2ea0321fc5da0d4ec0f1) that summarizes the usage of the `context` feature form `anyhow`:
 
 ```rust
 #[allow(unused_imports)]
@@ -211,6 +212,7 @@ fn main() {
 ```
 
 Which will output errors this way:
+
 ```
 Error string:
  Service could not do the important work
@@ -242,9 +244,9 @@ Error pretty:
 
 ## Consequences
 
-* We have defined the following aliases that should be used by default:
-    * `StdResult`: the default result that should be returned by a function (unless a more specific type is required).
-    * `StdError`: the default error that should be used (unless a more specific type is required).
+- We have defined the following aliases that should be used by default:
+  - `StdResult`: the default result that should be returned by a function (unless a more specific type is required).
+  - `StdError`: the default error that should be used (unless a more specific type is required).
 
 ```rust
 /* Code extracted from mithril-common::lib.rs */
@@ -255,14 +257,16 @@ pub type StdError = anyhow::Error;
 pub type StdResult<T> = anyhow::Result<T, StdError>;
 ```
 
-* The function that returns an error from a sub-system should systematically add a context to the error with the `with_context` method, in order to provide clear stack traces and ease debugging.
+- The function that returns an error from a sub-system should systematically add a context to the error with the `with_context` method, in order to provide clear stack traces and ease debugging.
+
+- When printing an `StdError` we should use the debug format without the pretty modifier, ie:
 
-* When printing an `StdError` we should use the debug format without the pretty modifier, ie: 
 ```rust
 println!("Error debug:\n {error:?}\n\n");
 ```
 
-* When wrapping an error in a `thiserror` enum variant we should use the `source` attribute that will provide a clearer stack trace:
+- When wrapping an error in a `thiserror` enum variant we should use the `source` attribute that will provide a clearer stack trace:
+
 ```rust
 /// Correct usage with `source` attribute
 #[derive(Error, Debug)]
@@ -281,8 +285,9 @@ pub enum DomainError {
 }
 ```
 
-* Here are some tips on how to discriminate between creating a new error using `thiserror` or using an `StdResult`:
-  * If you raise an anyhow error which only contains a string this means that you are creating a new error that doesn't come from a sub-system. In that case you should create a type using `thiserror` intead, ie:
+- Here are some tips on how to discriminate between creating a new error using `thiserror` or using an `StdResult`:
+  - If you raise an anyhow error which only contains a string this means that you are creating a new error that doesn't come from a sub-system. In that case you should create a type using `thiserror` intead, ie:
+
 ```rust
 // Avoid
 return Err(anyhow!("my new error"));
@@ -295,5 +300,5 @@ pub enum MyError {
 return Err(MyError::MyNewError);
 ```
 
-  * (*Still undecided*) You should avoid wrapping a `StdError` in a `thiserror` type. This __breaks__ the stack trace and makes it really difficult to retrieve the innermost errors using `downcast_ref`. When the `thiserror` type is itself wrapped in a `StdError` afterward, you would have to `downcast_ref` twice: first to get the `thiserror` type and then to get the innermost error. 
+- (_Still undecided_) You should avoid wrapping a `StdError` in a `thiserror` type. This **breaks** the stack trace and makes it really difficult to retrieve the innermost errors using `downcast_ref`. When the `thiserror` type is itself wrapped in a `StdError` afterward, you would have to `downcast_ref` twice: first to get the `thiserror` type and then to get the innermost error.
   This should be restricted to the topmost errors of our system (ie the state machine errors).

docs/website/adr/007-standardize-log-output.md

@@ -3,7 +3,7 @@ slug: 7
 title: |
   7. Standardize log output
 authors:
-- name: Mithril Team
+  - name: Mithril Team
 tags: [Accepted]
 date: 2024-04-07
 ---
@@ -14,16 +14,16 @@ Accepted
 
 ## Context
 
-* [ADR 2](/adr/2) is not completely relevant now, we have migrated recently the logs in the client to `stderr`. Only the result of the command execution is in `stdout`. This makes it possible to exploit the result, see our [blog post](/dev-blog/2024/02/26/mithril-client-cli-output-breaking-change).
-* Mithril aggregator logs are always redirected to `stdout` but it mixes 2 types of CLI commands, some of which would benefit from the logs output to `stderr`.
-* Mithril aggregator and Mithril client CLI have not a consistent log strategy, that's why we need to standardize them.
+- [ADR 2](/adr/2) is not completely relevant now, we have migrated recently the logs in the client to `stderr`. Only the result of the command execution is in `stdout`. This makes it possible to exploit the result, see our [blog post](/dev-blog/2024/02/26/mithril-client-cli-output-breaking-change).
+- Mithril aggregator logs are always redirected to `stdout` but it mixes 2 types of CLI commands, some of which would benefit from the logs output to `stderr`.
+- Mithril aggregator and Mithril client CLI have not a consistent log strategy, that's why we need to standardize them.
 
 ## Decision
 
-* For commands that provide a result or execute an action, logs are sent to `stderr`. Only the result of the command is sent to `stdout`.
-* For commands that launch a program without an expected result (server), logs are sent to `stdout`.
+- For commands that provide a result or execute an action, logs are sent to `stderr`. Only the result of the command is sent to `stdout`.
+- For commands that launch a program without an expected result (server), logs are sent to `stdout`.
 
 ## Consequences
 
-* End users who use `stdout` logs would have a breaking change. They will have to retrieve the logs that come from `stderr` in addition.
-* Commands `genesis`, `era` and `tools` from Mithril aggregator now send their logs to `stderr`.
+- End users who use `stdout` logs would have a breaking change. They will have to retrieve the logs that come from `stderr` in addition.
+- Commands `genesis`, `era` and `tools` from Mithril aggregator now send their logs to `stderr`.

docs/website/babel.config.js

@@ -1,3 +1,3 @@
 module.exports = {
-  presets: [require.resolve('@docusaurus/core/lib/babel/preset')],
+  presets: [require.resolve("@docusaurus/core/lib/babel/preset")],
 };