Add linkspector CI action (#3939)

Signed-off-by: Stephen Buttolph <[email protected]>
Co-authored-by: meaghanfitzgerald <[email protected]>

Author: StephenButtolph

.github/workflows/ci.yml

@@ -130,6 +130,14 @@ jobs:
           push: false
           # This version should match the version installed in the nix dev shell
           version: 1.47.2
+  links-lint:
+    name: Markdown Links Lint
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: umbrelladocs/action-linkspector@a0567ce1c7c13de4a2358587492ed43cab5d0102 #v1.3.4
+        with:
+          fail_level: any
   check_generated_protobuf:
     name: Up-to-date protobuf
     runs-on: ubuntu-latest

.linkspector.yml

@@ -0,0 +1,8 @@
+dirs:
+  - .
+excludedFiles:
+  - RELEASES.md # This file has too many links to efficiently check
+ignorePatterns:
+  - pattern: '^http://localhost.*$'              # Localhost links are used during tutorials
+  - pattern: "^https://.+\\.avax-dev\\.network$" # This check doesn't have the correct credentials
+useGitIgnore: true

README.md

@@ -187,7 +187,7 @@ For more information, refer to the [GRPC Golang Quick Start Guide](https://grpc.
 
 ### Running mock codegen
 
-See [the Contributing document autogenerated mocks section](CONTRIBUTING.md#Autogenerated-mocks).
+See [the Contributing document autogenerated mocks section](CONTRIBUTING.md####Autogenerated-mocks).
 
 ## Versioning
 

api/metrics/service.md

@@ -20,6 +20,6 @@ curl -X POST 127.0.0.1:9650/ext/metrics
 
 ## Format
 
-This API produces Prometheus compatible metrics. See [here](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md) for information on Prometheus' formatting.
+This API produces Prometheus compatible metrics. See [here](https://prometheus.io/docs/instrumenting/exposition_formats) for information on Prometheus' formatting.
 
 [Here](https://build.avax.network/docs/nodes/maintain/monitoring) is a tutorial that shows how to set up Prometheus and Grafana to monitor AvalancheGo node using the Metrics API.

config/config.md

@@ -384,7 +384,7 @@ Path to a JSON file containing the genesis data to use. Ignored when running
 standard networks (Mainnet, Fuji Testnet), or when `--genesis-content` is
 specified. If not given, uses default genesis data.
 
-See the documentation for the genesis JSON format [here](https://github.com/ava-labs/avalanchego/blob/master/genesis/README.md) and an example used for the local network genesis [here](https://github.com/ava-labs/avalanchego/blob/master/genesis/).
+See the documentation for the genesis JSON format [here](../genesis/README.md) and an example used for the local network genesis [here](../genesis/genesis_local.json).
 
 
 #### `--genesis-file-content` (string)

genesis/README.md

@@ -1,6 +1,6 @@
 # Genesis
 
-The Genesis package converts formatted JSON files into the genesis of the Primary Network. For the simplest example, see the [Local Genesis](https://github.com/ava-labs/avalanchego/blob/master/genesis/genesis_local.json) JSON file.
+The Genesis package converts formatted JSON files into the genesis of the Primary Network. For the simplest example, see the [Local Genesis](./genesis_local.json) JSON file.
 
 The genesis JSON file contains the following properties:
 

snow/README.md

@@ -45,17 +45,17 @@ All messaging functions in `OutboundMsgBuilder` can be categorized as follows:
 
 Currently, Avalanchego implements its own message serialization to communicate. In the future, Avalanchego will use protocol buffers to communicate.
 
-### [Network](https://github.com/ava-labs/avalanchego/blob/master/network/network.go)
+### [Network](../network/network.go)
 
 The networking interface is shared across all chains. It implements functions from the `ExternalSender` interface. The two functions it implements are `Send` and `Gossip`. `Send` sends a message of type `OutboundMessage` to a specific set of nodes (specified by an array of `NodeIDs`). `Gossip` sends a message of type `OutboundMessage` to a random group of nodes in a subnet (can be a validator or a non-validator). Gossiping is used to push transactions across the network. The networking protocol uses TLS to pass messages between peers.
 
 Along with sending and gossiping, the networking library is also responsible for making connections and maintaining connections. Any node whether they are a validator or non-validator will attempt to connect to the primary network.
 
-## [Router](https://github.com/ava-labs/avalanchego/blob/master/snow/networking/router/chain_router.go)
+## [Router](./networking/router/chain_router.go)
 
 The `ChainRouter` routes all incoming messages to its respective blockchain using `ChainID`. It does this by pushing all the messages onto the respective Chain handler’s queue. The `ChainRouter` references all existing chains on the network such as the X-chain, C-chain, P-chain and possibly any other chain. The `ChainRouter` handles timeouts as well. When sending messages on the P2P layer, timeouts are registered on the sender and cleared on the `ChainRouter` side when a response is received. If no response is received, then we trigger a timeout. Because we handle timeouts on the `ChainRouter` side, the handler is reliable. Peers not responding means timeouts trigger and the `ChainRouter` will still notify the handler of failure cases. The timeout manager within `ChainRouter` is also adaptive. If the network is experiencing long latencies, timeouts will then be adjusted as well.
 
-## [Handler](https://github.com/ava-labs/avalanchego/blob/master/snow/networking/handler/handler.go)
+## [Handler](./networking/handler/handler.go)
 
 The main function of the `Handler` is to pass messages from the network to the consensus engine. It receives these messages from the `ChainRouter`. It passes messages by pushing them onto a sync or async queue (depends on message type). Messages are then popped from the queue, parsed, and routed to the correct function in consensus engine. This can be one of the following.
 
@@ -64,14 +64,14 @@ The main function of the `Handler` is to pass messages from the network to the c
 - **Consensus message (sync queue)**
 - **App message (async queue)**
 
-## [Sender](https://github.com/ava-labs/avalanchego/blob/master/snow/networking/sender/sender.go)
+## [Sender](./networking/sender/sender.go)
 
 The main role of the `sender` is to build and send outbound messages. It is actually a very thin wrapper around the normal networking code. The main difference here is that sender registers timeouts and tells the [router] to expect a response message. The timer starts on the sender side. If there is no response, sender will send a failed response to the [router]. If a node is repeatedly unresponsive, that node will get benched and sender will immediately start marking those messages as failed. If a sufficient amount of network deems the node benched, it might not get rewards (as a validator).
 
-## [Consensus Engine](https://github.com/ava-labs/avalanchego/blob/master/snow/consensus/snowman/consensus.go)
+## [Consensus Engine](./consensus/snowman/consensus.go)
 
 Consensus is defined as getting a group of distributed systems to agree on an outcome. In the case of the Avalanche network, consensus is achieved when validators are in agreement with the state of the blockchain. The novel consensus algorithm is documented in the [white paper](https://assets.website-files.com/5d80307810123f5ffbb34d6e/6009805681b416f34dcae012_Avalanche%20Consensus%20Whitepaper.pdf). There are two main consensus algorithms: Avalanche and Snowman. The engine is responsible for proposing a new block to consensus, repeatedly polling the network for decisions (accept/reject), and communicating that decision to the `Sender`.
 
-## [Blockchain Creation](https://github.com/ava-labs/avalanchego/blob/master/chains/manager.go)
+## [Blockchain Creation](../chains/manager.go)
 
 The `Manager` is what kickstarts everything in regards to blockchain creation, starting with the P-Chain. Once the P-Chain finishes bootstrapping, it will kickstart C-Chain and X-Chain and any other chain. The `Manager`’s job is not done yet, if a create chain transaction is seen by a validator, a whole new process to create a chain will be started by the `Manager`. This can happen dynamically, long after the original 3 chains are created and bootstrapped.

tests/antithesis/README.md

@@ -1,7 +1,7 @@
 # Antithesis Testing
 
 This package supports testing with
-[Antithesis](https://antithesis.com/docs/introduction/introduction.html),
+[Antithesis](https://antithesis.com/docs/introduction/how_antithesis_works),
 a SaaS offering that enables deployment of distributed systems (such
 as Avalanche) to a deterministic and simulated environment that
 enables discovery and reproduction of anomalous behavior.

tests/e2e/README.md

@@ -26,7 +26,7 @@ flags.
 In cases where a change can be verified against only a subset of
 tests, it is possible to filter the tests that will be executed by the
 declarative labels that have been applied to them. Available labels
-are defined as constants in [`describe.go`](./describe.go) with names
+are defined as constants in [`describe.go`](../fixture/e2e/describe.go) with names
 of the form `*Label`. The following example runs only those tests that
 primarily target the X-Chain:
 
@@ -40,7 +40,7 @@ queries](https://onsi.github.io/ginkgo/#spec-labels).
 
 ## Adding tests
 
-Define any flags/configurations in [`e2e.go`](./e2e.go).
+Define any flags/configurations in [`flags.go`](../fixture/e2e/flags.go).
 
 Create a new package to implement feature-specific tests, or add tests to an existing package. For example:
 
@@ -135,4 +135,4 @@ until stopped by `tmpnetctl stop-collectors`.
 The results of collection will be viewable at
 https://grafana-poc.avax-dev.network.
 
-For more detail, see the [tmpnet docs](../tmpnet/README.md#monitoring).
+For more detail, see the [tmpnet docs](../fixture/tmpnet/README.md##monitoring).

tests/fixture/e2e/describe.go

@@ -9,7 +9,7 @@ const (
 	// For label usage in ginkgo invocation, see: https://onsi.github.io/ginkgo/#spec-labels
 
 	// Label for filtering a test that is not primarily a C-Chain test
-	// but nonentheless uses the C-Chain. Intended to support
+	// but nonetheless uses the C-Chain. Intended to support
 	// execution of all C-Chain tests by the coreth repo in an e2e job.
 	UsesCChainLabel = "uses-c"
 )

vms/example/xsvm/README.md

@@ -22,7 +22,7 @@ Just as [Coreth] powers the [C-Chain], XSVM can be used to power its own blockch
 
 ## How it Works
 
-XSVM utilizes AvalancheGo's [teleporter] package to create and authenticate Subnet Messages.
+XSVM utilizes AvalancheGo's [interchain messaging] package to create and authenticate Subnet Messages.
 
 ### Transfer
 
@@ -121,7 +121,7 @@ type Client interface {
     ctx context.Context,
     txID ids.ID,
     options ...rpc.Option,
-  ) (*teleporter.UnsignedMessage, []byte, error)
+  ) (*warp.UnsignedMessage, []byte, error)
 }
 ```
 
@@ -283,7 +283,7 @@ P-Chain.
 
 You can do this by following the [subnet tutorial] or by using the [subnet-cli].
 
-[teleporter]: https://github.com/ava-labs/avalanchego/tree/master/vms/platformvm/teleporter
+[interchain messaging]: https://github.com/ava-labs/avalanchego/tree/master/vms/platformvm/warp/README.md
 [subnet tutorial]: https://build.avax.network/docs/tooling/create-avalanche-l1
 [Coreth]: https://github.com/ava-labs/coreth
 [C-Chain]: https://build.avax.network/docs/quick-start/primary-network#c-chain