Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: add markdownlint to lint commands #9353

Merged
merged 11 commits into from
May 27, 2021
17 changes: 17 additions & 0 deletions .markdownlint.json
Original file line number Diff line number Diff line change
@@ -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
}
3 changes: 3 additions & 0 deletions .markdownlintignore
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
CHANGELOG.md
docs/core/proto-docs.md
docs/node_modules
60 changes: 30 additions & 30 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -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!
Expand Down Expand Up @@ -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.

Expand Down Expand Up @@ -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`)
Expand Down Expand Up @@ -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
Expand All @@ -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
Expand All @@ -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**
Expand Down
7 changes: 7 additions & 0 deletions Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand Down
5 changes: 1 addition & 4 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand All @@ -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

Expand Down
8 changes: 5 additions & 3 deletions SECURITY.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand All @@ -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
Expand All @@ -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.
Expand Down
37 changes: 20 additions & 17 deletions STABLE_RELEASES.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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
Expand Down Expand Up @@ -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:

Expand Down
6 changes: 3 additions & 3 deletions contrib/githooks/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@
Installation:

```
$ git config core.hooksPath contrib/githooks
git config core.hooksPath contrib/githooks
```

## pre-commit
Expand All @@ -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.
1 change: 1 addition & 0 deletions contrib/rosetta/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
13 changes: 8 additions & 5 deletions cosmovisor/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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:

```
Expand Down Expand Up @@ -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.
Expand Down Expand Up @@ -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,
Expand All @@ -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.
Expand Down Expand Up @@ -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:

```
Expand Down
Loading