chore: add markdownlint to lint commands (cosmos#9353)

* add markdownlint config * update make lint commands * update markdownlint config * run make lint-fix * fix empty link * resuse docker container * run lint-fix * do not echo commands Co-authored-by: ryanchrypto <[email protected]>
likhita-809 · May 27, 2021 · cb66c99 · cb66c99
1 parent b56e1a1
commit cb66c99
Show file tree

Hide file tree

Showing 147 changed files with 806 additions and 771 deletions.
diff --git a/.markdownlint.json b/.markdownlint.json
@@ -0,0 +1,17 @@
+{
+    "default": true,
+    "MD001": false,
+    "MD004": false,
+    "MD007": { "indent": 4 },
+    "MD013": false,
+    "MD024": { "siblings_only": true },
+    "MD025": false,
+    "MD026": { "punctuation": ".,;:" },
+    "MD029": false,
+    "MD033": false,
+    "MD034": false,
+    "MD036": false,
+    "MD040": false,
+    "MD041": false,
+    "no-hard-tabs": false
+}
diff --git a/.markdownlintignore b/.markdownlintignore
@@ -0,0 +1,3 @@
+CHANGELOG.md
+docs/core/proto-docs.md
+docs/node_modules
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -1,21 +1,21 @@
 # Contributing
 
 - [Contributing](#contributing)
-  - [Architecture Decision Records (ADR)](#architecture-decision-records-adr)
-  - [Pull Requests](#pull-requests)
-    - [Process for reviewing PRs](#process-for-reviewing-prs)
-    - [Updating Documentation](#updating-documentation)
-  - [Forking](#forking)
-  - [Dependencies](#dependencies)
-  - [Protobuf](#protobuf)
-  - [Testing](#testing)
-  - [Branching Model and Release](#branching-model-and-release)
-    - [PR Targeting](#pr-targeting)
-    - [Development Procedure](#development-procedure)
-    - [Pull Merge Procedure](#pull-merge-procedure)
-    - [Release Procedure](#release-procedure)
-    - [Point Release Procedure](#point-release-procedure)
-  - [Code Owner Membership](#code-owner-membership)
+    - [Architecture Decision Records (ADR)](#architecture-decision-records-adr)
+    - [Pull Requests](#pull-requests)
+        - [Process for reviewing PRs](#process-for-reviewing-prs)
+        - [Updating Documentation](#updating-documentation)
+    - [Forking](#forking)
+    - [Dependencies](#dependencies)
+    - [Protobuf](#protobuf)
+    - [Testing](#testing)
+    - [Branching Model and Release](#branching-model-and-release)
+        - [PR Targeting](#pr-targeting)
+        - [Development Procedure](#development-procedure)
+        - [Pull Merge Procedure](#pull-merge-procedure)
+        - [Release Procedure](#release-procedure)
+        - [Point Release Procedure](#point-release-procedure)
+    - [Code Owner Membership](#code-owner-membership)
 
 Thank you for considering making contributions to Cosmos-SDK and related
 repositories!
@@ -80,12 +80,12 @@ All PRs require two Reviews before merge (except docs changes, or variable name-
 
 - `LGTM` without an explicit approval means that the changes look good, but you haven't pulled down the code, run tests locally and thoroughly reviewed it.
 - `Approval` through the GH UI means that you understand the code, documentation/spec is updated in the right places, you have pulled down and tested the code locally. In addition:
-  - You must also think through anything which ought to be included but is not
-  - You must think through whether any added code could be partially combined (DRYed) with existing code
-  - You must think through any potential security issues or incentive-compatibility flaws introduced by the changes
-  - Naming must be consistent with conventions and the rest of the codebase
-  - Code must live in a reasonable location, considering dependency structures (e.g. not importing testing modules in production code, or including example code modules in production code).
-  - if you approve of the PR, you are responsible for fixing any of the issues mentioned here and more
+    - You must also think through anything which ought to be included but is not
+    - You must think through whether any added code could be partially combined (DRYed) with existing code
+    - You must think through any potential security issues or incentive-compatibility flaws introduced by the changes
+    - Naming must be consistent with conventions and the rest of the codebase
+    - Code must live in a reasonable location, considering dependency structures (e.g. not importing testing modules in production code, or including example code modules in production code).
+    - if you approve of the PR, you are responsible for fixing any of the issues mentioned here and more
 - If you sat down with the PR submitter and did a pairing review please note that in the `Approval`, or your PR comments.
 - If you are only making "surface level" reviews, submit any notes as `Comments` without adding a review.
 
@@ -229,10 +229,10 @@ should be targeted against the release candidate branch.
 - Create the release candidate branch `rc/v*` (going forward known as **RC**)
   and ensure it's protected against pushing from anyone except the release
   manager/coordinator
-  - **no PRs targeting this branch should be merged unless exceptional circumstances arise**
+    - **no PRs targeting this branch should be merged unless exceptional circumstances arise**
 - On the `RC` branch, prepare a new version section in the `CHANGELOG.md`
-  - All links must be link-ified: `$ python ./scripts/linkify_changelog.py CHANGELOG.md`
-  - Copy the entries into a `RELEASE_CHANGELOG.md`, this is needed so the bot knows which entries to add to the release page on github.
+    - All links must be link-ified: `$ python ./scripts/linkify_changelog.py CHANGELOG.md`
+    - Copy the entries into a `RELEASE_CHANGELOG.md`, this is needed so the bot knows which entries to add to the release page on github.
 - Kick off a large round of simulation testing (e.g. 400 seeds for 2k blocks)
 - If errors are found during the simulation testing, commit the fixes to `master`
   and create a new `RC` branch (making sure to increment the `rcN`)
@@ -314,22 +314,21 @@ have had acted maliciously or grossly negligent, code-owner privileges may be
 stripped with no prior warning or consent from the member in question.
 
 Other potential removal criteria:
-  * Missing 3 scheduled meetings results in ICF evaluating whether the member should be
+
+* Missing 3 scheduled meetings results in ICF evaluating whether the member should be
     removed / replaced
-  * Violation of Code of Conduct
+* Violation of Code of Conduct
 
 Earning this privilege should be considered to be no small feat and is by no
 means guaranteed by any quantifiable metric. It is a symbol of great trust of
 the community of this project.
 
-
 ## Concept & Release Approval Process
 
 The process for how Cosmos SDK maintainers take features and ADRs from concept to release
 is broken up into three distinct stages: **Strategy Discovery**, **Concept Approval**, and
 **Implementation & Release Approval**
 
-
 ### Strategy Discovery
 
 * Develop long term priorities, strategy and roadmap for the SDK
@@ -356,6 +355,7 @@ the current state of its discussion.
 
 If an ADR is taking longer than 4 weeks to reach a final conclusion, the **Concept Approval Committee**
 should convene to rectify the situation by either:
+
 - unanimously setting a new time bound period for this ADR
 - making changes to the Concept Approval Process (as outlined here)
 - making changes to the members of the Concept Approval Committee
@@ -378,8 +378,8 @@ Members must:
 * Be active contributors to the SDK, and furthermore should be continuously making substantial contributions
   to the project's codebase, review process, documentation and ADRs
 * Have stake in the Cosmos SDK project, represented by:
-  * Being a client / user of the Comsos SDK
-  * "[giving back](https://www.debian.org/social_contract)" to the software
+    * Being a client / user of the Comsos SDK
+    * "[giving back](https://www.debian.org/social_contract)" to the software
 * Delegate representation in case of vacation or absence
 
 Code owners need to maintain participation in the process, ideally as members of **Concept Approval Committee**

diff --git a/Makefile b/Makefile
@@ -327,11 +327,18 @@ benchmark:
 ###                                Linting                                  ###
 ###############################################################################
 
+containerMarkdownLintImage=tmknom/markdownlint
+containerMarkdownLint=cosmos-sdk-markdownlint
+containerMarkdownLintFix=cosmos-sdk-markdownlint-fix
+
 lint:
 	golangci-lint run --out-format=tab
+	@if docker ps -a --format '{{.Names}}' | grep -Eq "^${containerMarkdownLint}$$"; then docker start -a $(containerMarkdownLint); else docker run --name $(containerMarkdownLint) -i -v "$(CURDIR):/work" $(containerMarkdownLintImage); fi
 
 lint-fix:
 	golangci-lint run --fix --out-format=tab --issues-exit-code=0
+	@if docker ps -a --format '{{.Names}}' | grep -Eq "^${containerMarkdownLintFix}$$"; then docker start -a $(containerMarkdownLintFix); else docker run --name $(containerMarkdownLintFix) -i -v "$(CURDIR):/work" $(containerMarkdownLintImage) . --fix; fi
+
 .PHONY: lint lint-fix
 
 format:

diff --git a/README.md b/README.md
@@ -40,9 +40,6 @@ parent:
     <img alt="Lint Satus" src="https://github.com/cosmos/cosmos-sdk/workflows/Lint/badge.svg" />
 </div>
 
-
-
-
 The Cosmos-SDK is a framework for building blockchain applications in Golang.
 It is being used to build [`Gaia`](https://github.com/cosmos/gaia), the first implementation of the Cosmos Hub.
 
@@ -65,7 +62,7 @@ The Cosmos Hub application, `gaia`, has moved to its [own repository](https://gi
 
 ## Interblockchain Communication (IBC)
 
-The IBC module for the SDK has moved to its [own repository](https://github.com/cosmos/ibc-go). Go there to build and integrate with the IBC module. 
+The IBC module for the SDK has moved to its [own repository](https://github.com/cosmos/ibc-go). Go there to build and integrate with the IBC module.
 
 ## Starport
 

diff --git a/SECURITY.md b/SECURITY.md
@@ -51,7 +51,7 @@ the code.
 
 - HD key derivation, local and Ledger, and all key-management functionality
 - Side-channel attack vectors with our implementations
-  - e.g. key exfiltration based on time or memory-access patterns when decrypting privkey
+    - e.g. key exfiltration based on time or memory-access patterns when decrypting privkey
 
 ## Disclosure Process
 
@@ -73,6 +73,7 @@ This process can take some time. Every effort is made to handle the bug in as ti
 ### Disclosure Communications
 
 Communications to partners usually include the following details:
+
 1. Affected version or versions
 1. New release version
 1. Impact on user funds
@@ -81,13 +82,14 @@ Communications to partners usually include the following details:
 1. Potential required actions if an adverse condition arises during the security release process
 
 An example notice looks like:
+
 ```
 Dear Cosmos SDK partners,
 
-A critical security vulnerability has been identified in Cosmos SDK vX.X.X. 
+A critical security vulnerability has been identified in Cosmos SDK vX.X.X.
 User funds are NOT at risk; however, the vulnerability can result in a chain halt.
 
-This notice is to inform you that on [[**March 1 at 1pm EST/6pm UTC**]], we will be releasing Cosmos SDK vX.X.Y to fix the security issue. 
+This notice is to inform you that on [[**March 1 at 1pm EST/6pm UTC**]], we will be releasing Cosmos SDK vX.X.Y to fix the security issue.
 We ask all validators to upgrade their nodes ASAP.
 
 If the chain halts, validators with sufficient voting power must upgrade and come online for the chain to resume.

diff --git a/STABLE_RELEASES.md b/STABLE_RELEASES.md
@@ -52,13 +52,13 @@ To smoothen the update to the latest stable release, the SDK includes a set of C
 ### What qualifies as a Stable Release Update (SRU)
 
 * **High-impact bugs**
-  * Bugs that may directly cause a security vulnerability.
-  * *Severe regressions* from a Cosmos-SDK's previous release. This includes all sort of issues
+    * Bugs that may directly cause a security vulnerability.
+    * *Severe regressions* from a Cosmos-SDK's previous release. This includes all sort of issues
     that may cause the core packages or the `x/` modules unusable.
-  * Bugs that may cause **loss of user's data**.
+    * Bugs that may cause **loss of user's data**.
 * Other safe cases:
-  * Bugs which don't fit in the aforementioned categories for which an obvious safe patch is known.
-  * Relatively small yet strictly non-breaking changes that introduce forward-compatible client
+    * Bugs which don't fit in the aforementioned categories for which an obvious safe patch is known.
+    * Relatively small yet strictly non-breaking changes that introduce forward-compatible client
     features to smoothen the migration to successive releases.
 
 ### What does not qualify as SRU
@@ -71,27 +71,29 @@ To smoothen the update to the latest stable release, the SDK includes a set of C
 
 Pull requests that fix bugs that fall in the following categories do not require a **Stable Release Exception** to be granted to be included in a stable point-release:
 
- * **Severe regressions**.
- * Bugs that may cause **client applications** to be **largely unusable**.
- * Bugs that may cause **state corruption or data loss**.
- * Bugs that may directly or indirectly cause a **security vulnerability**.
+* **Severe regressions**.
+* Bugs that may cause **client applications** to be **largely unusable**.
+* Bugs that may cause **state corruption or data loss**.
+* Bugs that may directly or indirectly cause a **security vulnerability**.
 
 ## What pull requests will NOT be automatically included in stable point-releases
 
 As rule of thumb, the following changes will **NOT** be automatically accepted into stable point-releases:
 
- * **State machine changes**.
- * **Client application's code-breaking changes**, i.e. changes that prevent client applications to *build without modifications* to the client application's source code.
+* **State machine changes**.
+* **Client application's code-breaking changes**, i.e. changes that prevent client applications to *build without modifications* to the client application's source code.
 
  In some circumstances, PRs that don't meet the aforementioned criteria might be raised and asked to be granted a *Stable Release Exception*.
 
 ## Stable Release Exception - Procedure
 
 1. Check that the bug is either fixed or not reproducible in `master`. It is, in general, not appropriate to release bug fixes for stable releases without first testing them in `master`. Please apply the label [0.42 «Stargate»](https://github.com/cosmos/cosmos-sdk/labels/0.42%20LTS%20%28Stargate%29) to the issue.
 2. Add a comment to the issue and ensure it contains the following information (see the bug template below):
- * **[Impact]** An explanation of the bug on users and justification for backporting the fix to the stable release.
- * A **[Test Case]** section containing detailed instructions on how to reproduce the bug.
- * A **[Regression Potential]** section with a clear assessment on how regressions are most likely to manifest as a result of the pull request that aims to fix the bug in the target stable release.
+
+* **[Impact]** An explanation of the bug on users and justification for backporting the fix to the stable release.
+* A **[Test Case]** section containing detailed instructions on how to reproduce the bug.
+* A **[Regression Potential]** section with a clear assessment on how regressions are most likely to manifest as a result of the pull request that aims to fix the bug in the target stable release.
+
 3. **Stable Release Managers** will review and discuss the PR. Once *consensus* surrounding the rationale has been reached and the technical review has successfully concluded, the pull request will be merged in the respective point-release target branch (e.g. `release/v0.42.x`) and the PR included in the point-release's respective milestone (e.g. `0.42.5`).
 
 ### Stable Release Exception - Bug template
@@ -119,9 +121,10 @@ according to the [stable release policy](#stable-release-policy) and [release pr
 Decisions are made by consensus.
 
 Their responsibilites include:
- * Driving the Stable Release Exception process.
- * Approving/rejecting proposed changes to a stable release series.
- * Executing the release process of stable point-releases in compliance with the [Point Release Procedure](CONTRIBUTING.md).
+
+* Driving the Stable Release Exception process.
+* Approving/rejecting proposed changes to a stable release series.
+* Executing the release process of stable point-releases in compliance with the [Point Release Procedure](CONTRIBUTING.md).
 
 The Stable Release Managers are appointed by the Interchain Foundation. Currently residing Stable Release Managers:
 

diff --git a/contrib/githooks/README.md b/contrib/githooks/README.md
@@ -3,7 +3,7 @@
 Installation:
 
 ```
-$ git config core.hooksPath contrib/githooks
+git config core.hooksPath contrib/githooks
 ```
 
 ## pre-commit
@@ -14,8 +14,8 @@ that all the aforementioned commands are installed and available
 in the user's search `$PATH` environment variable:
 
 ```
-$ go get golang.org/x/tools/cmd/goimports
-$ go get github.com/golangci/misspell/cmd/misspell@master
+go get golang.org/x/tools/cmd/goimports
+go get github.com/golangci/misspell/cmd/misspell@master
 ```
 
 It also runs `go mod tidy` and `golangci-lint` if available.
diff --git a/contrib/rosetta/README.md b/contrib/rosetta/README.md
@@ -5,6 +5,7 @@ This directory contains the files required to run the rosetta CI. It builds `sim
 ## docker-compose.yaml
 
 Builds:
+
 - cosmos-sdk simapp node, with prefixed data directory, keys etc. This is required to test historical balances.
 - faucet is required so we can test construction API, it was literally impossible to put there a deterministic address to request funds for
 - rosetta is the rosetta node used by rosetta-cli to interact with the cosmos-sdk app

diff --git a/cosmovisor/README.md b/cosmovisor/README.md
@@ -28,7 +28,7 @@ if there was an error.
 
 ## Data Folder Layout
 
-`$DAEMON_HOME/cosmovisor` is expected to belong completely to `cosmovisor` and 
+`$DAEMON_HOME/cosmovisor` is expected to belong completely to `cosmovisor` and
 subprocesses that are controlled by it. The folder content is organised as follows:
 
 ```
@@ -66,6 +66,7 @@ directory layout:
 ## Usage
 
 The system administrator admin is responsible for:
+
 * installing the `cosmovisor` binary and configure the host's init system (e.g. `systemd`, `launchd`, etc) along with the environmental variables appropriately;
 * installing the `genesis` folder manually;
 * installing the `upgrades/<name>` folders manually.
@@ -95,19 +96,21 @@ valid format to specify a download in such a message:
 
 1. Store an os/architecture -> binary URI map in the upgrade plan info field
 as JSON under the `"binaries"` key, eg:
+
 ```json
 {
   "binaries": {
     "linux/amd64":"https://example.com/gaia.zip?checksum=sha256:aec070645fe53ee3b3763059376134f058cc337247c978add178b6ccdfb0019f"
   }
 }
 ```
+
 2. Store a link to a file that contains all information in the above format (eg. if you want
 to specify lots of binaries, changelog info, etc without filling up the blockchain).
 
 e.g. `https://example.com/testnet-1001-info.json?checksum=sha256:deaaa99fda9407c4dbe1d04bd49bab0cc3c1dd76fa392cd55a9425be074af01e`
 
-This file contained in the link will be retrieved by [go-getter](https://github.com/hashicorp/go-getter) 
+This file contained in the link will be retrieved by [go-getter](https://github.com/hashicorp/go-getter)
 and the `"binaries"` field will be parsed as above.
 
 If there is no local binary, `DAEMON_ALLOW_DOWNLOAD_BINARIES=on`, and we can access a canonical url for the new binary,
@@ -120,7 +123,7 @@ or hijacks the DNS. go-getter will always ensure the downloaded file matches the
 is provided. go-getter will also handle unpacking archives into directories (so these download links should be
 a zip of all data in the `bin` directory).
 
-To properly create a checksum on linux, you can use the `sha256sum` utility. e.g. 
+To properly create a checksum on linux, you can use the `sha256sum` utility. e.g.
 `sha256sum ./testdata/repo/zip_directory/autod.zip`
 which should return `29139e1381b8177aec909fab9a75d11381cab5adf7d3af0c05ff1c9c117743a7`.
 You can also use `sha512sum` if you like longer hashes, or `md5sum` if you like to use broken hashes.
@@ -174,13 +177,13 @@ Submit a software upgrade proposal:
 ```
 ./build/simd tx gov submit-proposal software-upgrade test1 --title "upgrade-demo" --description "upgrade"  --from validator --upgrade-height 100 --deposit 10000000stake --chain-id test --keyring-backend test -y
 ```
- 
+
 Query the proposal to ensure it was correctly broadcast and added to a block:
 
 ```
 ./build/simd query gov proposal 1
 ```
- 
+
 Submit a `Yes` vote for the upgrade proposal:
 
 ```