Test nodejs image (tendermint#3921)

* Test nodejs image

Signed-off-by: Marko Baricevic <[email protected]>

* minor changes

* v in version

* version in swagger.yaml

.circleci/config.yml

@@ -216,11 +216,11 @@ jobs:
           name: Trigger website build
           command: |
             curl --silent \
-                 --show-error \
-                 -X POST \
-                 --header "Content-Type: application/json" \
-                 -d "{\"branch\": \"$CIRCLE_BRANCH\"}" \
-                 "https://circleci.com/api/v1.1/project/github/$CIRCLE_PROJECT_USERNAME/$WEBSITE_REPO_NAME/build?circle-token=$TENDERBOT_API_TOKEN" > response.json
+                --show-error \
+                -X POST \
+                --header "Content-Type: application/json" \
+                -d "{\"branch\": \"$CIRCLE_BRANCH\"}" \
+                "https://circleci.com/api/v1.1/project/github/$CIRCLE_PROJECT_USERNAME/$WEBSITE_REPO_NAME/build?circle-token=$TENDERBOT_API_TOKEN" > response.json
 
             RESULT=`jq -r '.status' response.json`
             MESSAGE=`jq -r '.message' response.json`
@@ -373,12 +373,12 @@ jobs:
     steps:
       - checkout
       - run:
-          name: Test RPC endpoints agsainst swagger documentation
+          name: Test RPC endpoints against swagger documentation
           command: |
             set -x
             export PATH=~/.local/bin:$PATH
 
-            # install node 11.15 and dredd
+            # install node and dredd
             ./scripts/get_nodejs.sh
 
             # build the binaries with a proper version of Go

CONTRIBUTING.md

@@ -2,7 +2,7 @@
 
 Thank you for considering making contributions to Tendermint and related repositories! Start by taking a look at the [coding repo](https://github.com/tendermint/coding) for overall information on repository workflow and standards.
 
-Please follow standard github best practices: fork the repo, branch from the tip of `master`, make some commits, and submit a pull request to `master`. 
+Please follow standard github best practices: fork the repo, branch from the tip of `master`, make some commits, and submit a pull request to `master`.
 See the [open issues](https://github.com/tendermint/tendermint/issues) for things we need help with!
 
 Before making a pull request, please open an issue describing the
@@ -21,25 +21,25 @@ Please make sure to use `gofmt` before every commit - the easiest way to do this
 
 Please note that Go requires code to live under absolute paths, which complicates forking.
 While my fork lives at `https://github.com/ebuchman/tendermint`,
-the code should never exist at  `$GOPATH/src/github.com/ebuchman/tendermint`.
+the code should never exist at `$GOPATH/src/github.com/ebuchman/tendermint`.
 Instead, we use `git remote` to add the fork as a new remote for the original repo,
-`$GOPATH/src/github.com/tendermint/tendermint `, and do all the work there.
+`$GOPATH/src/github.com/tendermint/tendermint`, and do all the work there.
 
 For instance, to create a fork and work on a branch of it, I would:
 
-  * Create the fork on github, using the fork button.
-  * Go to the original repo checked out locally (i.e. `$GOPATH/src/github.com/tendermint/tendermint`)
-  * `git remote rename origin upstream`
-  * `git remote add origin [email protected]:ebuchman/basecoin.git`
+- Create the fork on github, using the fork button.
+- Go to the original repo checked out locally (i.e. `$GOPATH/src/github.com/tendermint/tendermint`)
+- `git remote rename origin upstream`
+- `git remote add origin [email protected]:ebuchman/basecoin.git`
 
 Now `origin` refers to my fork and `upstream` refers to the tendermint version.
 So I can `git push -u origin master` to update my fork, and make pull requests to tendermint from there.
 Of course, replace `ebuchman` with your git handle.
 
 To pull in updates from the origin repo, run
 
-  * `git fetch upstream`
-  * `git rebase upstream/master` (or whatever branch you want)
+- `git fetch upstream`
+- `git rebase upstream/master` (or whatever branch you want)
 
 ## Dependencies
 
@@ -113,7 +113,7 @@ removed from the header in rpc responses as well.
 
 ## Branching Model and Release
 
-The main development branch is master. 
+The main development branch is master.
 
 Every release is maintained in a release branch named `vX.Y.Z`.
 
@@ -140,36 +140,35 @@ easy to reference the pull request where a change was introduced.
 
 #### Major Release
 
-1. start on `master` 
+1. start on `master`
 2. run integration tests (see `test_integrations` in Makefile)
 3. prepare release in a pull request against `master` (to be squash merged):
-    - copy `CHANGELOG_PENDING.md` to top of `CHANGELOG.md`
-    - run `python ./scripts/linkify_changelog.py CHANGELOG.md` to add links for
-      all issues
-    - run `bash ./scripts/authors.sh` to get a list of authors since the latest
-      release, and add the github aliases of external contributors to the top of
-      the changelog. To lookup an alias from an email, try `bash
-      ./scripts/authors.sh <email>`
-    - reset the `CHANGELOG_PENDING.md`
-    - bump versions
+   - copy `CHANGELOG_PENDING.md` to top of `CHANGELOG.md`
+   - run `python ./scripts/linkify_changelog.py CHANGELOG.md` to add links for
+     all issues
+   - run `bash ./scripts/authors.sh` to get a list of authors since the latest
+     release, and add the github aliases of external contributors to the top of
+     the changelog. To lookup an alias from an email, try `bash ./scripts/authors.sh <email>`
+   - reset the `CHANGELOG_PENDING.md`
+   - bump versions
 4. push your changes with prepared release details to `vX.X` (this will trigger the release `vX.X.0`)
 5. merge back to master (don't squash merge!)
 
 #### Minor Release
 
-If there were no breaking changes and you need to create a release nonetheless, 
-the procedure is almost exactly like with a new release above. 
+If there were no breaking changes and you need to create a release nonetheless,
+the procedure is almost exactly like with a new release above.
 
 The only difference is that in the end you create a pull request against the existing `X.X` branch.
 The branch name should match the release number you want to create.
-Merging this PR will trigger the next release. 
-For example, if the PR is against an existing 0.34 branch which already contains a v0.34.0 release/tag, 
+Merging this PR will trigger the next release.
+For example, if the PR is against an existing 0.34 branch which already contains a v0.34.0 release/tag,
 the patch version will be incremented and the created release will be v0.34.1.
 
 #### Backport Release
 
 1. start from the existing release branch you want to backport changes to (e.g. v0.30)
-Branch to a release/vX.X.X branch locally (e.g. release/v0.30.7)
+   Branch to a release/vX.X.X branch locally (e.g. release/v0.30.7)
 2. cherry pick the commit(s) that contain the changes you want to backport (usually these commits are from squash-merged PRs which were already reviewed)
 3. steps 2 and 3 from [Major Release](#major-release)
 4. push changes to release/vX.X.X branch
@@ -187,12 +186,12 @@ includes its continuous integration status using a badge in the `README.md`.
 ### RPC Testing
 
 If you contribute to the RPC endpoints it's important to document your changes in the [Swagger file](./docs/spec/rpc/swagger.yaml)
-To test your changes you should install `nodejs` version `v11.15.*` and run:
+To test your changes you should install `nodejs` and run:
 
 ```bash
 npm i -g dredd
 make build-linux build-contract-tests-hooks
 make contract-tests
-``` 
+```
 
 This command will popup a network and check every endpoint against what has been documented