From efad34a492e73fa49c573c71787da791de329ca3 Mon Sep 17 00:00:00 2001 From: Ekleog-NEAR <96595974+Ekleog-NEAR@users.noreply.github.com> Date: Mon, 20 Nov 2023 10:51:03 +0100 Subject: [PATCH] fix broken links, and add lint to auto-check them (#10217) --- .github/workflows/ci.yml | 9 +++++++++ CONTRIBUTING.md | 2 +- chain/chunks/README.md | 2 +- chain/epoch-manager/README.md | 2 +- chain/rosetta-rpc/README.md | 4 ++-- docs/architecture/README.md | 2 +- docs/architecture/gas/estimator.md | 2 +- docs/architecture/how/README.md | 2 +- docs/architecture/how/epoch.md | 3 +-- docs/architecture/how/gc.md | 3 --- docs/architecture/network.md | 4 ++-- docs/misc/README.md | 2 +- lychee.toml | 15 +++++++++++++++ runtime/near-vm/engine/README.md | 16 ---------------- runtime/near-vm/test-api/README.md | 16 ---------------- runtime/runtime-params-estimator/README.md | 2 +- 16 files changed, 37 insertions(+), 49 deletions(-) create mode 100644 lychee.toml diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 352875776d8..992b0edaa53 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -216,3 +216,12 @@ jobs: save-if: "false" # use the cache from nextest, but don’t double-save - run: ./chain/jsonrpc/build_errors_schema.sh - run: git diff --quiet ./chain/jsonrpc/res/rpc_errors_schema.json || exit 1 + + lychee_checks: + name: "Lychee Lints" + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + - uses: lycheeverse/lychee-action@2ac9f030ccdea0033e2510a23a67da2a2da98492 + with: + fail: true diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 784079259cc..3c2e07797e3 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -158,6 +158,6 @@ On [betanet](https://docs.near.org/docs/concepts/networks#betanet) we run nightly build from master with all the nightly protocol features enabled. Every five weeks, we stabilize some protocol features and make a release candidate for testnet. The process for feature stabilization can be found in [this -document](docs/protocol_upgrade.md). After the release candidate has been +document](docs/practices/protocol_upgrade.md). After the release candidate has been running on testnet for four weeks and no issues are observed, we stabilize and publish the release for mainnet. diff --git a/chain/chunks/README.md b/chain/chunks/README.md index 3515991f9a7..11807c33436 100644 --- a/chain/chunks/README.md +++ b/chain/chunks/README.md @@ -2,7 +2,7 @@ This crate cotains functions to handle chunks. In NEAR - the block consists of multiple chunks - at most one per shard. -When a chunk is created, the creator encodes its contents using Reed Solomon encoding (ErasureCoding) and adds cross-shard receipts - creating PartialEncodedChunks that are later sent to all the validators (each validator gets a subset of them). This is done for data availability reasons (so that we need only a part of the validators to reconstruct the whole chunk). You can read more about it in the Nightshade paper (https://near.org/nightshade/) +When a chunk is created, the creator encodes its contents using Reed Solomon encoding (ErasureCoding) and adds cross-shard receipts - creating PartialEncodedChunks that are later sent to all the validators (each validator gets a subset of them). This is done for data availability reasons (so that we need only a part of the validators to reconstruct the whole chunk). You can read more about it in [the Nightshade paper](https://near.org/papers/nightshade). A honest validator will only approve a block if it receives its assigned parts for all chunks in the block - which means that for each chunk, it has `has_all_parts()` returning true. diff --git a/chain/epoch-manager/README.md b/chain/epoch-manager/README.md index 060a9f8cc3c..0be415e9c97 100644 --- a/chain/epoch-manager/README.md +++ b/chain/epoch-manager/README.md @@ -21,7 +21,7 @@ EpochManager has also a lot of methords that allows you to fetch information fro ## RewardCalculator RewardCalculator is responsible for computing rewards for the validators at the end of the epoch, based on their block/chunk productions. -You can see more details on the https://nomicon.io/Economics/README.html#validator-rewards-calculation +You can see more details on [the Nomicon documentation](https://nomicon.io/Economics/Economic#validator-rewards-calculation). ## Validator Selection / proposals / proposals_to_epoch_info These files/functions are responsible for selecting the validators for the next epoch (and internally - also deciding which validator will produce which block and which chunk). diff --git a/chain/rosetta-rpc/README.md b/chain/rosetta-rpc/README.md index b770632b09d..03da45f4fbe 100644 --- a/chain/rosetta-rpc/README.md +++ b/chain/rosetta-rpc/README.md @@ -110,11 +110,11 @@ in production and will be located at `./target/release/neard`. Alternatively, during development and testing it may be better to follow the method recommended when [contributing to -nearcore](https://docs.near.org/docs/community/contribute/contribute-nearcore) +nearcore](https://github.com/near/nearcore/blob/master/CONTRIBUTING.md) which creates a slightly less optimised executable but does it faster: ```bash -cargo build --release --package neard --bin neard +cargo build --profile dev-release --package neard --bin neard ``` ## How to Configure diff --git a/docs/architecture/README.md b/docs/architecture/README.md index 6fe49db031c..b994a4d260b 100644 --- a/docs/architecture/README.md +++ b/docs/architecture/README.md @@ -255,7 +255,7 @@ starting point when reading the code base. The [tracing](https://tracing.rs) crate is used for structured, hierarchical event output and logging. We also integrate [Prometheus](https://prometheus.io) -for light-weight metric output. See the [style](./style.md) documentation for +for light-weight metric output. See the [style](../practices/style.md) documentation for more information on the usage. ### Testing diff --git a/docs/architecture/gas/estimator.md b/docs/architecture/gas/estimator.md index 5f898fe5588..0f33dac3de9 100644 --- a/docs/architecture/gas/estimator.md +++ b/docs/architecture/gas/estimator.md @@ -76,7 +76,7 @@ cloud-hosted VMs) and manual labor to set it up. The other supported metric `icount` is much more stable. It uses [qemu](https://www.qemu.org/) to emulate an x86 CPU. We then insert a custom -[TCG plugin](https://qemu.readthedocs.io/en/latest/devel/tcg-plugins.html) +[TCG plugin](https://www.qemu.org/docs/master/devel/tcg-plugins.html) ([counter.c](https://github.com/near/nearcore/blob/08c4a1bd4b16847eb1c2fccee36bf16f6efb71fd/runtime/runtime-params-estimator/emu-cost/counter_plugin/counter.c)) that counts the number of executed x86 instructions. It also intercepts system calls and counts the number of bytes seen in `sys_read`, `sys_write` and their diff --git a/docs/architecture/how/README.md b/docs/architecture/how/README.md index d3cc36d8155..6b50bacf8b7 100644 --- a/docs/architecture/how/README.md +++ b/docs/architecture/how/README.md @@ -116,7 +116,7 @@ peer. Once `ClientActor` realizes that it is more than `sync_height_threshold` to sync. The synchronization process is done in three steps: 1. Header sync. The node first identifies the headers it needs to sync through a - [`get_locator`](https://github.com/near/nearcore/blob/279044f09a7e6e5e3f26db4898af3655dae6eda6/chain/*client/src/sync.rs#L332) + [`get_locator`](https://github.com/near/nearcore/blob/279044f09a7e6e5e3f26db4898af3655dae6eda6/chain/client/src/sync.rs#L332) calculation. This is essentially an exponential backoff computation that tries to identify commonly known headers between the node and its peers. Then it would request headers from different peers, at most diff --git a/docs/architecture/how/epoch.md b/docs/architecture/how/epoch.md index a42b9276b9d..98e317b40e8 100644 --- a/docs/architecture/how/epoch.md +++ b/docs/architecture/how/epoch.md @@ -38,8 +38,7 @@ Epoch length is set in the genesis config. Currently in mainnet it is set to 432 "epoch_length": 43200 ``` - -See http://go/mainnet-genesis for more details. +See [the mainnet genesis](https://s3-us-west-1.amazonaws.com/build.nearprotocol.com/nearcore-deploy/mainnet/genesis.json) for more details. This means that each epoch lasts around 15 hours. diff --git a/docs/architecture/how/gc.md b/docs/architecture/how/gc.md index 4df22525964..9d22a975f28 100644 --- a/docs/architecture/how/gc.md +++ b/docs/architecture/how/gc.md @@ -69,6 +69,3 @@ Same as before, we’d remove up to 2 blocks in each run: ![](https://user-images.githubusercontent.com/1711539/195650127-b30865e1-d9c1-4950-8607-67d82a185b76.png) Until we catch up to the `gc_stop`. - -(the original drawings for this document are -[here](https://docs.google.com/document/d/1BiEuJqm4phwQbi-fjzHMZPzDL-94z9Dqkc3XPNnxKJM/edit?usp=sharing)) diff --git a/docs/architecture/network.md b/docs/architecture/network.md index 68e06086b99..6b7dd8fe5b5 100644 --- a/docs/architecture/network.md +++ b/docs/architecture/network.md @@ -441,7 +441,7 @@ This section describes different protocols of sending messages currently used in ## 10.1 Messages between Actors. `Near` is build on `Actix`'s `actor` -[framework](https://actix.rs/book/actix/sec-2-actor.html). Usually each actor +[framework](https://actix.rs/docs/actix/actor). Usually each actor runs on its own dedicated thread. Some, like `PeerActor` have one thread per each instance. Only messages implementing `actix::Message`, can be sent using between threads. Each actor has its own queue; Processing of messages @@ -474,7 +474,7 @@ or hash (which seems to be used only for route back...). If target is the account - it will be converted using `routing_table.account_owner` to the peer. Upon receiving the message, the `PeerManagerActor` -[will sign it](https://github.com/near/nearcore/blob/master/chain/network/src/peer_manager.rs#L1285) +[will sign it](https://github.com/near/nearcore/blob/cadf11d5851be7611011b4e89542e11f41f3d827/chain/network/src/peer_manager/peer_manager_actor.rs) and convert into RoutedMessage (which also have things like TTL etc.). Then it will use the `routing_table`, to find the route to the target peer (add diff --git a/docs/misc/README.md b/docs/misc/README.md index 3c40eb02c0e..eaaf54ee5ae 100644 --- a/docs/misc/README.md +++ b/docs/misc/README.md @@ -6,7 +6,7 @@ something, but don't know where to put it, put it here! ## Crate Versioning and Publishing While all the crates in the workspace are directly unversioned (`v0.0.0`), they -all share a unified variable version in the [workspace manifest](Cargo.toml). +all share a unified variable version in the [workspace manifest](../../Cargo.toml). This keeps versions consistent across the workspace and informs their versions at the moment of publishing. diff --git a/lychee.toml b/lychee.toml new file mode 100644 index 00000000000..9f15e84b582 --- /dev/null +++ b/lychee.toml @@ -0,0 +1,15 @@ +exclude = [ + # these are private repositories, presumably any link to it are in internal documentation only. + "^https://github.com/near/near-ops", + "^https://github.com/near/nearcore-private", + + # localhost is linked to refer to services supposed to be running on the host. + "^http://localhost", + + # jsonrpc internal links + "^file://.*/chain/jsonrpc/res/debug/", + + # used as placeholders for a template + "^https://github.com/near/nearcore/pull/XXXX$", + "^https://github.com/near/NEPs/blob/master/neps/nep-XXXX.md$", +] diff --git a/runtime/near-vm/engine/README.md b/runtime/near-vm/engine/README.md index e5eb1ac9c68..90669f8ce11 100644 --- a/runtime/near-vm/engine/README.md +++ b/runtime/near-vm/engine/README.md @@ -10,17 +10,6 @@ Wasmer Engines are mainly responsible for two things: * **Load** an`Artifact` so it can be used by the user (normally, pushing the code into executable memory and so on). -It currently has three implementations: - -1. Universal with [`wasmer-engine-universal`], -2. Native with [`wasmer-engine-dylib`], -3. Object with [`wasmer-engine-staticlib`]. - -## Example Implementation - -Please check [`wasmer-engine-dummy`] for an example implementation for -an `Engine`. - ### Acknowledgments This project borrowed some of the code of the trap implementation from @@ -29,10 +18,5 @@ the [`wasmtime-api`], the code since then has evolved significantly. Please check [Wasmer `ATTRIBUTIONS`] to further see licenses and other attributions of the project. - -[`wasmer-engine-universal`]: https://github.com/wasmerio/wasmer/tree/master/lib/engine-universal -[`wasmer-engine-dylib`]: https://github.com/wasmerio/wasmer/tree/master/lib/engine-dylib -[`wasmer-engine-staticlib`]: https://github.com/wasmerio/wasmer/tree/master/lib/engine-staticlib -[`wasmer-engine-dummy`]: https://github.com/wasmerio/wasmer/tree/master/tests/lib/engine-dummy [`wasmtime-api`]: https://crates.io/crates/wasmtime [Wasmer `ATTRIBUTIONS`]: https://github.com/wasmerio/wasmer/blob/master/ATTRIBUTIONS.md diff --git a/runtime/near-vm/test-api/README.md b/runtime/near-vm/test-api/README.md index 26b1e52a33a..3948f5ce27b 100644 --- a/runtime/near-vm/test-api/README.md +++ b/runtime/near-vm/test-api/README.md @@ -48,17 +48,6 @@ fn main() -> anyhow::Result<()> { Wasmer is not only fast, but also designed to be *highly customizable*: -* **Pluggable engines** — An engine is responsible to drive the - compilation process and to store the generated executable code - somewhere, either: - * in-memory (with [`wasmer-engine-universal`]), - * in a native shared object file (with [`wasmer-engine-dylib`], - `.dylib`, `.so`, `.dll`), then load it with `dlopen`, - * in a native static object file (with [`wasmer-engine-staticlib`]), - in addition to emitting a C header file, which both can be linked - against a sandboxed WebAssembly runtime environment for the - compiled module with no need for runtime compilation. - * **Pluggable compilers** — A compiler is used by an engine to transform WebAssembly into executable code: * [`wasmer-compiler-singlepass`] provides a fast compilation-time @@ -98,8 +87,3 @@ more](https://wasmerio.github.io/wasmer/crates/doc/wasmer/). --- Made with ❤️ by the Wasmer team, for the community - -[`wasmer-engine-universal`]: https://github.com/wasmerio/wasmer/tree/master/lib/engine-universal -[`wasmer-engine-dylib`]: https://github.com/wasmerio/wasmer/tree/master/lib/engine-dylib -[`wasmer-engine-staticlib`]: https://github.com/wasmerio/wasmer/tree/master/lib/engine-staticlib -[`wasmer-compiler-singlepass`]: https://github.com/wasmerio/wasmer/tree/master/lib/compiler-singlepass diff --git a/runtime/runtime-params-estimator/README.md b/runtime/runtime-params-estimator/README.md index 4c9ff748c97..38aba2aa788 100644 --- a/runtime/runtime-params-estimator/README.md +++ b/runtime/runtime-params-estimator/README.md @@ -27,7 +27,7 @@ Use this tool to measure the running time of elementary runtime operations that Rather, the costs are hard-codded in the `Default` impl for `RuntimeConfig`. You can run `cargo run --package runtime-params-estimator --bin runtime-params-estimator -- --costs-file costs.txt` to convert cost table into `RuntimeConfig`. -3. **Continuous Estimation**: Take a look at [`continuous-estimation/README.md`](./continuous-estimation/README.md) to learn about the automated setup around the parameter estimator. +3. **Continuous Estimation**: Take a look at [`estimator-warehouse/README.md`](./estimator-warehouse/README.md) to learn about the automated setup around the parameter estimator. Note, if you use the plotting functionality you would need to install [gnuplot](http://gnuplot.info/) to see the graphs.