Merge pull request #1218 from aeternity/feature/drop-node-5

refactor: drop compatibility with node@5

.env

@@ -1,2 +1,2 @@
-NODE_TAG=v5.10.1
-COMPILER_TAG=v4.3.2
+NODE_TAG=v6.0.0
+COMPILER_TAG=v6.0.0

.github/workflows/main.yml

@@ -0,0 +1,59 @@
+name: Test, build, and deploy
+on: [push, pull_request]
+jobs:
+  main:
+    runs-on: ubuntu-latest
+    steps:
+      - if: github.ref != 'refs/heads/develop'
+        uses: actions/checkout@v2
+        with:
+          ref: develop
+      - uses: actions/checkout@v2
+        with:
+          fetch-depth: 100
+      - if: github.ref != 'refs/heads/develop'
+        run: git branch develop origin/develop
+
+      - uses: actions/setup-node@v2
+        with:
+          node-version: 14.x
+      - uses: actions/cache@v2
+        with:
+          path: ~/.npm
+          key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
+
+      - run: npm ci --ignore-scripts
+      - run: npm run lint
+      - run: npm run build
+      - run: npm run test:unit
+
+      - uses: actions/setup-python@v2
+        with:
+          python-version: 3.8
+      - uses: actions/cache@v2
+        with:
+          path: ~/.cache/pip3
+          key: ${{ runner.os }}-pip-${{ hashFiles('docs/requirements.txt') }}
+      - run: pip3 install -r docs/requirements.txt
+      - run: mkdocs build
+
+      - run: docker-compose up -d
+      - name: Ensure that node is running
+        run: |
+          while [[ `curl -s -o /dev/null -w %{http_code} localhost:3013/api` != 200 ]]; do
+            sleep 0.2;
+          done
+
+      - run: npm run test:integration:channel,accounts
+      - run: npm run test:integration:contract,chain
+      - run: npm run test:integration:else
+      - run: npm run report-coverage
+        if: always()
+      - run: docker-compose logs
+        if: always()
+
+      - uses: peaceiris/actions-gh-pages@v3
+        if: github.ref == 'refs/heads/master'
+        with:
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          publish_dir: docs

commitlint.config.js

@@ -0,0 +1,3 @@
+module.exports = {
+  extends: ['@commitlint/config-conventional']
+}

docker-compose.yml

@@ -6,17 +6,12 @@ services:
     ports: ["3013:3013", "3113:3113", "3014:3014", "3114:3114"]
     environment:
       EPOCH_CONFIG: /home/aeternity/aeternity_node.yaml
-    command: bin/aeternity console -noinput -aecore expected_mine_rate ${EPOCH_MINE_RATE:-5000}
+    command: bin/aeternity console -noinput -aecore
     volumes:
       - ./docker/aeternity_node_mean16.yaml:/home/aeternity/aeternity_node.yaml
-      - ./docker/keys/node:/home/aeternity/node/keys
       - ./docker/accounts_test.json:/home/aeternity/node/data/aecore/.genesis/accounts_test.json
-      - node_db:/home/aeternity/node/data/mnesia
 
   compiler:
     image: aeternity/aesophia_http:${COMPILER_TAG}
     hostname: compiler
     ports: ["3080:3080"]
-
-volumes:
-  node_db:

docker/aeternity_node_mean16.yaml

@@ -8,23 +8,19 @@ http:
     debug_endpoints: true
     port: 3113
     listen_address: 0.0.0.0
+  endpoints:
+    dry-run: true
 
 websocket:
   channel:
     listen_address: 0.0.0.0
     port: 3014
 
-keys:
-  peer_password: "top secret"
-  dir: ./keys
-
 chain:
   persist: false
   hard_forks:
     "1": 0
-    "2": 2
-    "3": 4
-    "4": 6
+    "5": 1
 
 mining:
   autostart: true

docs/contrib/releases.md

@@ -11,8 +11,6 @@ them in order to achieve this. In addition, the user needs to activate any means
 of 2-factor authentication because the `aepp-sdk` package is set up to only
 accept new versions if a second factor for authentication is in use.
 
-> This is in light of the latest `eslint-scope` hack.
-
 As new releases should only happen from release branch merges to the `master`
 branch of the repository on GitHub followed by a signed tag push, the user also
 needs direct write access to [the repository] on GitHub. Normally, this can be
@@ -25,36 +23,42 @@ achieved by first adding them to the [æternity organization] and then to the
 
 ## Branching Out
 
-As aepp-sdk follows the [git-flow strategy] for develoment, the release process
+As aepp-sdk follows the [git-flow strategy] for development, the release process
 is modelled after that strategy accordingly, with a few additions.
 
 Branch out from `develop` to a dedicated release branch denoting the target
-version number, e.g. `release/0.20.0-0.1.0` for a hypothetical first release
-targeting Node 0.20.0.
+version number, e.g. `release/v2.3.4`.
 
 [git-flow strategy]: https://danielkummer.github.io/git-flow-cheatsheet/
 
 ## Preparing a Pre-Release
 
-If Testnet is not yet targeting the latest Node version, but you're "ready to release", you can do a pre-release for the latest version, tagging the release as `@next` on npmjs.
+If Testnet is not yet targeting the latest Node version, but you're "ready to
+release", you can do a pre-release for the latest version, tagging the release
+as `@next` on npmjs.
 
-To do this, You can follow the steps listed below, while keeping the `next` portion in both `CHANGELOG.md` and `package.json` files.
+To do this, You can follow the steps listed below, while keeping the `next`
+portion in both `CHANGELOG.md` and `package.json` files.
 
 ## Preparing a Release
 
 On the release branch, remove the `next` portion of the `version`
-string in `package.json`. Replace the `[Unreleased]` header in the
-[change log file], if you have that, with the new version string.
-Next, `git diff` the release, branch a `release/X.X.X` (where `X.X.X` is your latest release) against `master` and validate that all changes are covered in the changelog. You can find more instructions on how to maintain a CHANGELOG: [here](http://keepachangelog.com).
+string in `package.json`.
 
-Also, make sure to add a new link at the bottom of the file that will
-provide a diff between the last released version and the to-be released
-version.
+Execute `npm run release` to automatically
+ - update [change log file]
+ - bump version number in package.json and package-lock.json (according to
+   [Semantic Versioning])
+ - output changes to CHANGELOG.md
+ - commit package-lock.json and package.json and CHANGELOG.md
 
-There's a catch: That link won't be able to work until after the release has
-been made!
+Next, `git diff` the release, branch a `release/vX.X.X` (where `vX.X.X` is your
+latest release) against `master` and validate that all changes are covered in
+the changelog. You can find more instructions on how to maintain a CHANGELOG:
+[here](http://keepachangelog.com).
 
 [change log file]: ../CHANGELOG.md
+[Semantic Versioning]: https://semver.org
 
 ## PR against `master`
 
@@ -65,8 +69,10 @@ separately.
 
 ## Merging
 
-Once the integration build has succesfully completed (with or without additional
-fixes), *merge* (without squash) the branch into `master`. This allows `master` to be comprised of release commits exclusively, so every commit on master correponds to exactly one released (or at least, tagged) version of aepp-sdk, respectively.
+Once the integration build has successfully completed (with or without additional
+fixes), *merge* (without squash) the branch into `master`. This allows `master`
+to be comprised of release commits exclusively, so every commit on master corresponds
+to exactly one released (or at least, tagged) version of aepp-sdk, respectively.
 
 ## Build, Release and Tag
 
@@ -79,26 +85,31 @@ releasing, perform a full clean and build in order to release to npmjs.com!
 
 1. Cleanup - run `git clean -ffdx` to completely wipe out your workspace of
    files not in the repository. This might wipe out files you still need, so
-   consider a seperate clone of the project!
-2. Execute `npm run prepublishOnly` to generate Documentation for the API and the SDK codebase, optionally followed by `npm pack` and investigate the resulting tarball's contents. This tarball resembles what
-   users will actual download from npmjs.com once the release is completed!
+   consider a separate clone of the project!
+2. Execute `npm run prepublishOnly` to generate Documentation for the API and
+   the SDK codebase, optionally followed by `npm pack` and investigate the
+   resulting tarball's contents. This tarball resembles what
+   users will actually download from npmjs.com once the release is completed!
 3. Execute `npm publish` and follow the on-screen instructions
 
-**Important:** If you are releasing a Pre-Release (AKA `next`), make sure to tag the release as `next` using the command `npm publish --tag next`.
+**Important:** If you are releasing a Pre-Release (AKA `next`), make sure to
+tag the release as `next` using the command `npm publish --tag next`.
 
 At this point, the release should already be in npmjs.com. The final step is to
 also tag the release on GitHub and push the tag, *which requires direct write
 access*.
 
-1. `git tag $VERSION`
-2. `git push tag $VERSION`
+1. `git tag vX.X.X`
+2. `git push tag vX.X.X`
 
 > Recommendation: Use signed tags using the -s option to increase community's
 > trust in the project!
 
 ## Merging Back into `develop`
 
 At this point, it is important to synchronize `develop` with any changes that
-have happened after branching out to the release branch. Create a new branch called `realign/X.X.X` from `master` (where `X.X.X` is your latest release) and open a Pull Request towards `develop` and resolve conflicts, if needed.
+have happened after branching out to the release branch. Create a new branch
+called `realign/vX.X.X` from `master` (where `vX.X.X` is your latest release)
+and open a Pull Request towards `develop` and resolve conflicts, if needed.
 
 This concludes the release process and the development cycle.