From 8ca175200e6055cfc42ab423fcc082ec112de59e Mon Sep 17 00:00:00 2001 From: srdtrk <59252793+srdtrk@users.noreply.github.com> Date: Mon, 18 Mar 2024 21:51:14 +0700 Subject: [PATCH] docs: fix some broken links (#6012) * docs(e2e): fixed broken link * docs: fixed architecture links * docs: fixed more broken links * docs: fixed some interchain accounts links * fix: more links * imp: updated markdownlint-cli2 API * docs: ran linter --- Makefile | 4 ++-- docs/architecture/README.md | 4 ++-- docs/docs/01-ibc/04-middleware/02-develop.md | 2 +- .../docs/02-apps/02-interchain-accounts/02-development.md | 8 ++++---- docs/docs/03-light-clients/04-wasm/01-overview.md | 2 +- docs/requirements/ics29-v1-requirements.md | 2 +- .../02-apps/02-interchain-accounts/02-development.md | 2 +- .../02-apps/02-interchain-accounts/02-development.md | 2 +- .../03-light-clients/04-wasm/01-overview.md | 2 +- .../version-v8.1.x/01-ibc/04-middleware/02-develop.md | 2 +- .../02-apps/02-interchain-accounts/02-development.md | 2 +- .../03-light-clients/04-wasm/01-overview.md | 2 +- e2e/README.md | 4 ++-- 13 files changed, 19 insertions(+), 19 deletions(-) diff --git a/Makefile b/Makefile index 6ff6bc42ece..ac929270114 100644 --- a/Makefile +++ b/Makefile @@ -337,7 +337,7 @@ docs-lint: #? docs-lint-fix: Lint markdown documentation files and fix docs-lint-fix: - markdownlint-cli2-fix "**.md" + markdownlint-cli2 "**.md" --fix #? docs-link-check: Run markdown-link-check docs-link-check: @@ -390,4 +390,4 @@ proto-update-deps: help: Makefile @echo " Choose a command run in "$(PROJECT_NAME)":" @sed -n 's/^#?//p' $< | column -t -s ':' | sort | sed -e 's/^/ /' -.PHONY: help \ No newline at end of file +.PHONY: help diff --git a/docs/architecture/README.md b/docs/architecture/README.md index 2846a813569..d619f655f67 100644 --- a/docs/architecture/README.md +++ b/docs/architecture/README.md @@ -25,7 +25,7 @@ If recorded decisions turned out to be lacking, convene a discussion, record the Note the context/background should be written in the present tense. -To suggest an ADR, please make use of the [ADR template](./adr.template.md) provided. +To suggest an ADR, please make use of the [ADR template](https://github.com/cosmos/ibc-go/blob/main/docs/architecture/adr.template.md) provided. ## Table of Contents @@ -37,7 +37,7 @@ To suggest an ADR, please make use of the [ADR template](./adr.template.md) prov | [004](./adr-004-ics29-lock-fee-module.md) | ICS29 module locking upon escrow out of balance | Accepted | | [005](./adr-005-consensus-height-events.md) | `UpdateClient` events - `ClientState` consensus heights | Accepted | | [006](./adr-006-02-client-refactor.md) | ICS02 client refactor | Accepted | -| [007](./adr-007-solomachine-signbytes.md) | ICS06 Solo machine sign bytes | +| [007](./adr-007-solomachine-signbytes.md) | ICS06 Solo machine sign bytes | Accepted | | [008](./adr-008-app-caller-cbs.md) | Callback to IBC ACtors | Accepted | | [009](./adr-009-v6-ics27-msgserver.md) | ICS27 message server addition | Accepted | | [010](./adr-010-light-clients-as-sdk-modules.md) | IBC light clients as SDK modules | Accepted | diff --git a/docs/docs/01-ibc/04-middleware/02-develop.md b/docs/docs/01-ibc/04-middleware/02-develop.md index 0f6ad9ea01c..9ae53985af7 100644 --- a/docs/docs/01-ibc/04-middleware/02-develop.md +++ b/docs/docs/01-ibc/04-middleware/02-develop.md @@ -283,7 +283,7 @@ See [here](https://github.com/cosmos/ibc-go/blob/v7.0.0/modules/apps/29-fee/ibc_ #### Capabilities -The middleware should simply pass the capability in the callback arguments along to the underlying application so that it may be claimed by the base application. The base application will then pass the capability up the stack in order to authenticate an outgoing packet/acknowledgement, which you can check in the [`ICS4Wrapper` section](02-develop.md#ics-4-wrappers). +The middleware should simply pass the capability in the callback arguments along to the underlying application so that it may be claimed by the base application. The base application will then pass the capability up the stack in order to authenticate an outgoing packet/acknowledgement, which you can check in the [`ICS4Wrapper` section](#ics-04-wrappers). In the case where the middleware wishes to send a packet or acknowledgment without the involvement of the underlying application, it should be given access to the same `scopedKeeper` as the base application so that it can retrieve the capabilities by itself. diff --git a/docs/docs/02-apps/02-interchain-accounts/02-development.md b/docs/docs/02-apps/02-interchain-accounts/02-development.md index c42696cc514..0440de5255b 100644 --- a/docs/docs/02-apps/02-interchain-accounts/02-development.md +++ b/docs/docs/02-apps/02-interchain-accounts/02-development.md @@ -15,7 +15,7 @@ This document will outline potential use cases and redirect each use case to the ## Custom authentication Interchain accounts may be associated with alternative types of authentication relative to the traditional public/private key signing. -If you wish to develop or use Interchain Accounts with a custom authentication module and do not need to execute custom logic on the packet callbacks, we recommend you use ibc-go v6 or greater and that your custom authentication module interacts with the controller submodule via the [`MsgServer`](05-messages.md). +If you wish to develop or use Interchain Accounts with a custom authentication module and do not need to execute custom logic on the packet callbacks, we recommend you use ibc-go v6 or greater and that your custom authentication module interacts with the controller submodule via the [`MsgServer`](./05-messages.md). If you wish to consume and execute custom logic in the packet callbacks, then please read the section [Packet callbacks](#packet-callbacks) below. @@ -26,7 +26,7 @@ To facilitate such an action, the controller submodule may be provided an underl An improved design has been suggested in [ADR 008](https://github.com/cosmos/ibc-go/pull/1976) which performs this action via middleware. Implementers of this use case are recommended to follow the ADR 008 approach. -The underlying application may continue to be used as a short term solution for ADR 008 and the [legacy API](03-auth-modules.md#registerinterchainaccount) should continue to be utilized in such situations. +The underlying application may continue to be used as a short term solution for ADR 008 and the [legacy API](./10-legacy/01-auth-modules.md) should continue to be utilized in such situations. ## Packet callbacks @@ -35,6 +35,6 @@ If a developer requires access to packet callbacks for their use case, then they 1. Write a smart contract which is connected via an ADR 008 or equivalent IBC application (recommended). 2. Use the controller's underlying application to implement packet callback logic. -In the first case, the smart contract should use the [`MsgServer`](05-messages.md). +In the first case, the smart contract should use the [`MsgServer`](./05-messages.md). -In the second case, the underlying application should use the [legacy API](10-legacy/03-keeper-api.md). +In the second case, the underlying application should use the [legacy API](./10-legacy/03-keeper-api.md). diff --git a/docs/docs/03-light-clients/04-wasm/01-overview.md b/docs/docs/03-light-clients/04-wasm/01-overview.md index 8af3bcb899b..a41f15e6793 100644 --- a/docs/docs/03-light-clients/04-wasm/01-overview.md +++ b/docs/docs/03-light-clients/04-wasm/01-overview.md @@ -13,7 +13,7 @@ Learn about the `08-wasm` light client proxy module. ### Context -Traditionally, light clients used by ibc-go have been implemented only in Go, and since ibc-go v7 (with the release of the 02-client refactor), they are [first-class Cosmos SDK modules](../../../architecture/adr-010-light-clients-as-sdk-modules.md). This means that updating existing light client implementations or adding support for new light clients is a multi-step, time-consuming process involving on-chain governance: it is necessary to modify the codebase of ibc-go (if the light client is part of its codebase), re-build chains' binaries, pass a governance proposal and have validators upgrade their nodes. +Traditionally, light clients used by ibc-go have been implemented only in Go, and since ibc-go v7 (with the release of the 02-client refactor), they are [first-class Cosmos SDK modules](/architecture/adr-010-light-clients-as-sdk-modules). This means that updating existing light client implementations or adding support for new light clients is a multi-step, time-consuming process involving on-chain governance: it is necessary to modify the codebase of ibc-go (if the light client is part of its codebase), re-build chains' binaries, pass a governance proposal and have validators upgrade their nodes. ### Motivation diff --git a/docs/requirements/ics29-v1-requirements.md b/docs/requirements/ics29-v1-requirements.md index 6af639939a8..f3607dad7b8 100644 --- a/docs/requirements/ics29-v1-requirements.md +++ b/docs/requirements/ics29-v1-requirements.md @@ -92,7 +92,7 @@ See section [Definitions](https://github.com/cosmos/ibc/tree/main/spec/app/ics-0 | 4.08 | Only packets that have been sent may be incentivized. | [Acceptance test](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/keeper/msg_server_test.go#L376) | `Verified` | | 4.09 | A packet sent may be incentivized for some or all of `MsgRecvPacket`, `MsgAcknowledgement`, `MsgTimeout`. | Fees for any of the messages may be zero, but [not all of them](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/types/fee.go#L87). | `Verified` | | 4.10 | Only packets that have not gone through the packet life cycle (i.e. have not been acknowledged or timed out yet) may be incentivized. | [Acceptance test](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/keeper/msg_server_test.go#L382-L410) | `Verified` | -| 4.11 | If a channel exists, a packet sent may be incentivized. | [Acceptance test](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/keeper/msg_server_test.go#L365) | +| 4.11 | If a channel exists, a packet sent may be incentivized. | [Acceptance test](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/keeper/msg_server_test.go#L365) | `Verified` | | 4.12 | If a channel is fee-enabled, a packet sent may be incentivized. | [Acceptance test](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/keeper/msg_server_test.go#L357) | `Verified` | | 4.13 | If the fee module is not locked, a packet sent may be incentivized. | [Acceptance test](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/keeper/msg_server_test.go#L350) | `Verified` | | 4.14 | A non-valid `Bech32` account address shall not be allowed to incentivize a packet sent. | [Acceptance test](https://github.com/cosmos/ibc-go/blob/v4.0.0/modules/apps/29-fee/keeper/msg_server_test.go#L412) | `Verified` | diff --git a/docs/versioned_docs/version-v6.2.x/02-apps/02-interchain-accounts/02-development.md b/docs/versioned_docs/version-v6.2.x/02-apps/02-interchain-accounts/02-development.md index e7bca4114ba..4d41be20daf 100644 --- a/docs/versioned_docs/version-v6.2.x/02-apps/02-interchain-accounts/02-development.md +++ b/docs/versioned_docs/version-v6.2.x/02-apps/02-interchain-accounts/02-development.md @@ -26,7 +26,7 @@ To facilitate such an action, the controller submodule may be provided an underl An improved design has been suggested in [ADR 008](https://github.com/cosmos/ibc-go/pull/1976) which performs this action via middleware. Implementers of this use case are recommended to follow the ADR 008 approach. -The underlying application may continue to be used as a short term solution for ADR 008 and the [legacy API](03-auth-modules.md#registerinterchainaccount) should continue to be utilized in such situations. +The underlying application may continue to be used as a short term solution for ADR 008 and the [legacy API](./09-legacy/01-auth-modules.md) should continue to be utilized in such situations. ## Packet callbacks diff --git a/docs/versioned_docs/version-v7.3.x/02-apps/02-interchain-accounts/02-development.md b/docs/versioned_docs/version-v7.3.x/02-apps/02-interchain-accounts/02-development.md index 58b9e4e67aa..db2e37f4b26 100644 --- a/docs/versioned_docs/version-v7.3.x/02-apps/02-interchain-accounts/02-development.md +++ b/docs/versioned_docs/version-v7.3.x/02-apps/02-interchain-accounts/02-development.md @@ -26,7 +26,7 @@ To facilitate such an action, the controller submodule may be provided an underl An improved design has been suggested in [ADR 008](https://github.com/cosmos/ibc-go/pull/1976) which performs this action via middleware. Implementers of this use case are recommended to follow the ADR 008 approach. -The underlying application may continue to be used as a short term solution for ADR 008 and the [legacy API](03-auth-modules.md#registerinterchainaccount) should continue to be utilized in such situations. +The underlying application may continue to be used as a short term solution for ADR 008 and the [legacy API](./10-legacy/01-auth-modules.md) should continue to be utilized in such situations. ## Packet callbacks diff --git a/docs/versioned_docs/version-v7.3.x/03-light-clients/04-wasm/01-overview.md b/docs/versioned_docs/version-v7.3.x/03-light-clients/04-wasm/01-overview.md index c3677fa162a..a41f15e6793 100644 --- a/docs/versioned_docs/version-v7.3.x/03-light-clients/04-wasm/01-overview.md +++ b/docs/versioned_docs/version-v7.3.x/03-light-clients/04-wasm/01-overview.md @@ -13,7 +13,7 @@ Learn about the `08-wasm` light client proxy module. ### Context -Traditionally, light clients used by ibc-go have been implemented only in Go, and since ibc-go v7 (with the release of the 02-client refactor), they are [first-class Cosmos SDK modules](../../../../architecture/adr-010-light-clients-as-sdk-modules.md). This means that updating existing light client implementations or adding support for new light clients is a multi-step, time-consuming process involving on-chain governance: it is necessary to modify the codebase of ibc-go (if the light client is part of its codebase), re-build chains' binaries, pass a governance proposal and have validators upgrade their nodes. +Traditionally, light clients used by ibc-go have been implemented only in Go, and since ibc-go v7 (with the release of the 02-client refactor), they are [first-class Cosmos SDK modules](/architecture/adr-010-light-clients-as-sdk-modules). This means that updating existing light client implementations or adding support for new light clients is a multi-step, time-consuming process involving on-chain governance: it is necessary to modify the codebase of ibc-go (if the light client is part of its codebase), re-build chains' binaries, pass a governance proposal and have validators upgrade their nodes. ### Motivation diff --git a/docs/versioned_docs/version-v8.1.x/01-ibc/04-middleware/02-develop.md b/docs/versioned_docs/version-v8.1.x/01-ibc/04-middleware/02-develop.md index 0f6ad9ea01c..9ae53985af7 100644 --- a/docs/versioned_docs/version-v8.1.x/01-ibc/04-middleware/02-develop.md +++ b/docs/versioned_docs/version-v8.1.x/01-ibc/04-middleware/02-develop.md @@ -283,7 +283,7 @@ See [here](https://github.com/cosmos/ibc-go/blob/v7.0.0/modules/apps/29-fee/ibc_ #### Capabilities -The middleware should simply pass the capability in the callback arguments along to the underlying application so that it may be claimed by the base application. The base application will then pass the capability up the stack in order to authenticate an outgoing packet/acknowledgement, which you can check in the [`ICS4Wrapper` section](02-develop.md#ics-4-wrappers). +The middleware should simply pass the capability in the callback arguments along to the underlying application so that it may be claimed by the base application. The base application will then pass the capability up the stack in order to authenticate an outgoing packet/acknowledgement, which you can check in the [`ICS4Wrapper` section](#ics-04-wrappers). In the case where the middleware wishes to send a packet or acknowledgment without the involvement of the underlying application, it should be given access to the same `scopedKeeper` as the base application so that it can retrieve the capabilities by itself. diff --git a/docs/versioned_docs/version-v8.1.x/02-apps/02-interchain-accounts/02-development.md b/docs/versioned_docs/version-v8.1.x/02-apps/02-interchain-accounts/02-development.md index c42696cc514..ab3dbfe412e 100644 --- a/docs/versioned_docs/version-v8.1.x/02-apps/02-interchain-accounts/02-development.md +++ b/docs/versioned_docs/version-v8.1.x/02-apps/02-interchain-accounts/02-development.md @@ -26,7 +26,7 @@ To facilitate such an action, the controller submodule may be provided an underl An improved design has been suggested in [ADR 008](https://github.com/cosmos/ibc-go/pull/1976) which performs this action via middleware. Implementers of this use case are recommended to follow the ADR 008 approach. -The underlying application may continue to be used as a short term solution for ADR 008 and the [legacy API](03-auth-modules.md#registerinterchainaccount) should continue to be utilized in such situations. +The underlying application may continue to be used as a short term solution for ADR 008 and the [legacy API](./10-legacy/01-auth-modules.md) should continue to be utilized in such situations. ## Packet callbacks diff --git a/docs/versioned_docs/version-v8.1.x/03-light-clients/04-wasm/01-overview.md b/docs/versioned_docs/version-v8.1.x/03-light-clients/04-wasm/01-overview.md index c3677fa162a..a41f15e6793 100644 --- a/docs/versioned_docs/version-v8.1.x/03-light-clients/04-wasm/01-overview.md +++ b/docs/versioned_docs/version-v8.1.x/03-light-clients/04-wasm/01-overview.md @@ -13,7 +13,7 @@ Learn about the `08-wasm` light client proxy module. ### Context -Traditionally, light clients used by ibc-go have been implemented only in Go, and since ibc-go v7 (with the release of the 02-client refactor), they are [first-class Cosmos SDK modules](../../../../architecture/adr-010-light-clients-as-sdk-modules.md). This means that updating existing light client implementations or adding support for new light clients is a multi-step, time-consuming process involving on-chain governance: it is necessary to modify the codebase of ibc-go (if the light client is part of its codebase), re-build chains' binaries, pass a governance proposal and have validators upgrade their nodes. +Traditionally, light clients used by ibc-go have been implemented only in Go, and since ibc-go v7 (with the release of the 02-client refactor), they are [first-class Cosmos SDK modules](/architecture/adr-010-light-clients-as-sdk-modules). This means that updating existing light client implementations or adding support for new light clients is a multi-step, time-consuming process involving on-chain governance: it is necessary to modify the codebase of ibc-go (if the light client is part of its codebase), re-build chains' binaries, pass a governance proposal and have validators upgrade their nodes. ### Motivation diff --git a/e2e/README.md b/e2e/README.md index 2d377b6f872..7d37307c306 100644 --- a/e2e/README.md +++ b/e2e/README.md @@ -63,7 +63,7 @@ The images which are used only exist on your machine. These environment variables allow us to run tests with arbitrary versions (from branches or released) of simd and the go relayer. -Every time changes are pushed to a branch or to `main`, a new `simd` image is built and pushed [here](https://github.com/cosmos/ibc-go/pkgs/container/ibc-go-simd). +Every time changes are pushed to a branch or to `main`, a new `simd` image is built and pushed [here](https://github.com/orgs/cosmos/packages?repo_name=ibc-go). ### Example Command @@ -232,7 +232,7 @@ There are two main github actions for e2e tests. [e2e-fork.yaml](https://github.com/cosmos/ibc-go/blob/main/.github/workflows/e2e-fork.yml) which runs when forks are created. -In `e2e.yaml`, the `simd` image is built and pushed to [a registry](https://github.com/cosmos/ibc-go/pkgs/container/ibc-go-simd) and every test +In `e2e.yaml`, the `simd` image is built and pushed to [a registry](https://github.com/orgs/cosmos/packages?repo_name=ibc-go) and every test that is run uses the image that was built. In `e2e-fork.yaml`, images are not pushed to this registry, but instead remain local to the host runner.