Release 1.8.0

.github/workflows/benchmark.yml

@@ -43,7 +43,7 @@ jobs:
           key: ${{ runner.os }}-${{ steps.node.outputs.v8CppApiVersion }}-${{ hashFiles('**/yarn.lock', '**/package.json') }}
       - name: Install & build
         if: steps.cache-deps.outputs.cache-hit != 'true'
-        run: yarn install --frozen-lockfile --ignore-optional && yarn build
+        run: yarn install --frozen-lockfile && yarn build
       - name: Build
         run: yarn build
         if: steps.cache-deps.outputs.cache-hit == 'true'

.github/workflows/docs.yml

@@ -27,7 +27,7 @@ jobs:
           key: ${{ runner.os }}-${{ steps.node.outputs.v8CppApiVersion }}-${{ hashFiles('**/yarn.lock', '**/package.json') }}
       - name: Install & build
         if: steps.cache-deps.outputs.cache-hit != 'true'
-        run: yarn install --frozen-lockfile --ignore-optional && yarn build
+        run: yarn install --frozen-lockfile && yarn build
       - name: Build
         run: yarn build
         if: steps.cache-deps.outputs.cache-hit == 'true'

.github/workflows/lint-pr-title.yml

@@ -0,0 +1,56 @@
+name: "Lint PR title"
+
+on:
+  pull_request_target:
+    types:
+      - opened
+      - edited
+      - synchronize
+      - labeled
+      - unlabeled
+
+jobs:
+  main:
+    name: Validate PR title
+    runs-on: ubuntu-latest
+    steps:
+      - uses: amannn/action-semantic-pull-request@v5
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        with:
+          # Configure which types are allowed (newline-delimited).
+          # Default: https://github.com/commitizen/conventional-commit-types
+          #types: |
+
+          # Configure which scopes are allowed (newline-delimited).
+          # These are regex patterns auto-wrapped in `^ $`.
+          #scopes: |
+
+          # Configure that a scope must always be provided.
+          requireScope: false
+
+          # Configure which scopes are disallowed in PR titles (newline-delimited).
+          # For instance by setting the value below, `chore(release): ...` (lowercase)
+          # and `ci(e2e,release): ...` (unknown scope) will be rejected.
+          # These are regex patterns auto-wrapped in `^ $`.
+          #disallowScopes: |
+
+          # Configure additional validation for the subject based on a regex.
+          # This example ensures the subject doesn't start with an uppercase character.
+          subjectPattern: ^(?![A-Z]).+$
+
+          # If `subjectPattern` is configured, you can use this property to override
+          # the default error message that is shown when the pattern doesn't match.
+          # The variables `subject` and `title` can be used within the message.
+          subjectPatternError: |
+            The subject "{subject}" found in the pull request title "{title}"
+            didn't match the configured pattern. Please ensure that the subject
+            doesn't start with an uppercase character.
+
+          # If the PR contains one of these newline-delimited labels, the
+          # validation is skipped. If you want to rerun the validation when
+          # labels change, you might want to use the `labeled` and `unlabeled`
+          # event triggers in your workflow.
+          ignoreLabels: |
+            bot
+            ignore-semantic-pull-request

.github/workflows/publish-dev.yml

@@ -35,7 +35,7 @@ jobs:
           key: ${{ runner.os }}-${{ steps.node.outputs.v8CppApiVersion }}-${{ hashFiles('**/yarn.lock', '**/package.json') }}
       - name: Install & build
         if: steps.cache-deps.outputs.cache-hit != 'true'
-        run: yarn install --frozen-lockfile --ignore-optional && yarn build
+        run: yarn install --frozen-lockfile && yarn build
       - name: Build
         run: yarn build
         if: steps.cache-deps.outputs.cache-hit == 'true'

.github/workflows/publish-rc.yml

@@ -68,7 +68,7 @@ jobs:
           key: ${{ runner.os }}-${{ steps.node.outputs.v8CppApiVersion }}-${{ hashFiles('**/yarn.lock', '**/package.json') }}
       - name: Install & build
         if: steps.cache-deps.outputs.cache-hit != 'true'
-        run: yarn install --frozen-lockfile --ignore-optional && yarn build
+        run: yarn install --frozen-lockfile && yarn build
       - name: Build
         run: yarn build
         if: steps.cache-deps.outputs.cache-hit == 'true'

.github/workflows/publish-stable.yml

@@ -74,7 +74,7 @@ jobs:
           key: ${{ runner.os }}-${{ steps.node.outputs.v8CppApiVersion }}-${{ hashFiles('**/yarn.lock', '**/package.json') }}
       - name: Install & build
         if: steps.cache-deps.outputs.cache-hit != 'true'
-        run: yarn install --frozen-lockfile --ignore-optional && yarn build
+        run: yarn install --frozen-lockfile && yarn build
       - name: Build
         run: yarn build
         if: steps.cache-deps.outputs.cache-hit == 'true'

.github/workflows/test-browser.yml

@@ -37,7 +37,7 @@ jobs:
           key: ${{ runner.os }}-${{ steps.node.outputs.v8CppApiVersion }}-${{ hashFiles('**/yarn.lock', '**/package.json') }}
       - name: Install & build
         if: steps.cache-deps.outputs.cache-hit != 'true'
-        run: yarn install --frozen-lockfile --ignore-optional && yarn build
+        run: yarn install --frozen-lockfile && yarn build
       - name: Build
         run: yarn build
         if: steps.cache-deps.outputs.cache-hit == 'true'

.github/workflows/test-e2e.yml

@@ -37,7 +37,7 @@ jobs:
           key: ${{ runner.os }}-${{ steps.node.outputs.v8CppApiVersion }}-${{ hashFiles('**/yarn.lock', '**/package.json') }}
       - name: Install & build
         if: steps.cache-deps.outputs.cache-hit != 'true'
-        run: yarn install --frozen-lockfile --ignore-optional && yarn build
+        run: yarn install --frozen-lockfile && yarn build
       - name: Build
         run: yarn build
         if: steps.cache-deps.outputs.cache-hit == 'true'

.github/workflows/test-sim-merge.yml

@@ -38,7 +38,7 @@ jobs:
           key: ${{ runner.os }}-${{ steps.node.outputs.v8CppApiVersion }}-${{ hashFiles('**/yarn.lock', '**/package.json') }}
       - name: Install & build
         if: steps.cache-deps.outputs.cache-hit != 'true'
-        run: yarn install --frozen-lockfile --ignore-optional && yarn build
+        run: yarn install --frozen-lockfile && yarn build
       - name: Build
         run: yarn build
         if: steps.cache-deps.outputs.cache-hit == 'true'

.github/workflows/test-sim.yml

@@ -35,7 +35,7 @@ jobs:
           key: ${{ runner.os }}-${{ steps.node.outputs.v8CppApiVersion }}-${{ hashFiles('**/yarn.lock', '**/package.json') }}
       - name: Install & build
         if: steps.cache-deps.outputs.cache-hit != 'true'
-        run: yarn install --frozen-lockfile --ignore-optional && yarn build
+        run: yarn install --frozen-lockfile && yarn build
       - name: Build
         run: yarn build
         if: steps.cache-deps.outputs.cache-hit == 'true'

.github/workflows/test-spec.yml

@@ -33,7 +33,7 @@ jobs:
           key: ${{ runner.os }}-${{ steps.node.outputs.v8CppApiVersion }}-${{ hashFiles('**/yarn.lock', '**/package.json') }}
       - name: Install & build
         if: steps.cache-deps.outputs.cache-hit != 'true'
-        run: yarn install --frozen-lockfile --ignore-optional && yarn build
+        run: yarn install --frozen-lockfile && yarn build
       - name: Build
         run: yarn build
         if: steps.cache-deps.outputs.cache-hit == 'true'

.github/workflows/test.yml

@@ -34,7 +34,7 @@ jobs:
           key: ${{ runner.os }}-${{ steps.node.outputs.v8CppApiVersion }}-${{ hashFiles('**/yarn.lock', '**/package.json') }}
       - name: Install & build
         if: steps.cache-deps.outputs.cache-hit != 'true'
-        run: yarn install --frozen-lockfile --ignore-optional && yarn build
+        run: yarn install --frozen-lockfile && yarn build
       - name: Build
         run: yarn build
         if: steps.cache-deps.outputs.cache-hit == 'true'

CONTRIBUTING.md

@@ -142,13 +142,25 @@ We're currently experimenting with hosting the majority of lodestar packages and
   - Use `/** **/` commenting format for documenting a function/variable.
 - Code whitespace can be helpful for reading complex code, please add some.
 - For unit tests, we forbid import stubbing when other approaches are feasible.
-- Logging framework: When determining which log level to use for providing information to users, consider the level of importance and whether the alert is actionable (Warning, Error, Fatal).
-  - Trace: Describes events showing step by step execution which can be ignored during standard operation.
-  - Debug: Useful information for debugging purposes.
-  - Info: Purely informative logs which can be ignored during normal operation.
-  - Warning: Unexpected behaviour, but the application continues to function and key operations are unaffected.
-  - Error: One or more main functionalities are not working, preventing some functions from working properly.
-  - Fatal: One or more main functionalities are not working and preventing the application from fulfilling its duties.
+
+## Logging policy
+
+### Logging Levels
+
+Contributors must choose the log level carefully to ensure a consistent experience for every type of user:
+
+- `error`: Critical issues that prevent the application from functioning correctly or cause significant disruption to users. Examples include failed network connections, crashes, or data corruption.
+- `warn`: Situations that may lead to critical issues if not addressed but do not prevent the application from functioning. Examples include configuration issues, deprecated features, or temporary network disruptions.
+- `info`: General sporadic informational about the node's state. Examples include initialization messages, infrequent periodic status updates, or high-level progress reports.
+- `debug`: Detailed diagnostic information that can help developers or users troubleshoot specific issues. Examples include individual request logs for every REST API, networking interactions, or internal components status changes. Alias to `verbose`.
+
+### Logging guidelines
+
+- Avoid excessive logging. Log messages should be clear and concise, providing enough information to understand the context and severity of the issue.
+- Do not log sensitive data, such as private keys, user credentials, or personal information.
+- Do not log arbitrary data from the network as ASCII or UTF8 at levels higher or equal to `info`.
+- Use clear and concise language. Prefer to log variables in JSON format `log.debug("Action", {slot})` instead of formatting the text yourself `log.debug('slot=${slot}')`.
+- Include only relevant context in log messages, sufficient to debug the issue or action it refers to.
 
 ## Contributing to Grafana dashboards
 

RELEASE.md

@@ -15,6 +15,7 @@ The causes for a release are varied, however here are several common ones:
 - To include a major bug-fix, optimization, or feature.
 - To include a series of small changes which have shown to improve performance, usability, etc.
 - If significant or risky PRs are waiting to merge and we wish to try and isolate those changes to a future release. I.e., to leave a "clean slate" for future PRs to apply to.
+- An external team or entity needs a specific feature that the team has agreed to publish.
 
 To start a new release, one of the Lodestar developers will communicate this via the Lodestar chat channel and seek consensus from the other developers.
 
@@ -23,6 +24,7 @@ To start a new release, one of the Lodestar developers will communicate this via
 #### All-in-one script (for example version `v1.1.0`, commit `9fceb02`):
 
 - The team selects a commit from `unstable` as a "release candidate" for a new version release.
+  - NOTE: In some rare circumstances, the team may select a commit from `stable`. This may happen if a tight deadline needs to be met and `unstable` can't be stabilized in time. We should avoid doing this unless absolutely necessary as merge conflicts and unintended consequences of cherry-picking commits may arise.
 - `yarn release:create-rc 1.1.0 9fceb02`
   - Must be run locally from a write-access account capable of triggering CI.
   - This script may alternatively be run on the checked out `HEAD`:
@@ -67,13 +69,13 @@ Tagging a release candidate will trigger CI to publish to NPM, dockerhub, and Gi
 
 Once a release candidate is created, the Lodestar team begins a testing period.
 
-If there is a bug discovered during the testing period which significantly impacts performance, security, or stability, and it is determined that it is no longer prudent to promote the `rc.x` candidate to `stable`, then it will await a bug fix by the team. The fix will be committed, maybe back-ported to `unstable` and we publish and promote the new commit to `rc.x+1`. The 3 day testing period will reset.
+If there is a bug discovered during the testing period which significantly impacts performance, security, or stability, and it is determined that it is no longer prudent to promote the `rc.x` candidate to `stable`, then it will await a bug fix by the team. The fix will be committed to `unstable` first, then cherrypicked into the `rc/v1.1.0` branch. Then we publish and promote the new commit to `rc.x+1`. The 3 day testing period will reset.
 
 For example: After 3-5 days of testing, is performance equal to or better than latest stable?
 
 - **Yes**: Continue to the next release step
 - **No**: If it a small issue fixable quickly (hot-fix)?
-  - **Yes**: push fixes to branch, go to step 2, incrementing the rc version
+  - **Yes**: Merge fix(es) to `unstable`, push the fix(es) to `rc/v1.1.0` branch, go to step 2, incrementing the rc version
   - **No**: abort the release. Close the `v1.1.0 release` PR, delete the branch, and start the whole release process over.
 
 ### 4. Merge release candidate
@@ -109,9 +111,56 @@ Tagging a stable release will trigger CI to publish to NPM, dockerhub, and Githu
 
 If a stable version requires an immediate hot-fix before the next release, a hot-fix release is started.
 
-The same process for a stable release is used, with the two differences.
+A similar process for a stable release is used, with the three differences.
 - The candidate commit must be chosen from the `stable` branch instead of the `unstable` branch.
 - Depending on the severity of the bug being fixed, the testing window may be decreased.
+- All hotfixes are committed with an `unstable` first strategy rather than directly on the RC branch itself. Hotfixes are always merged to `unstable` first, then cherry-picked into hotfix release candidates.
+
+### 1. Create hotfix release candidate from `stable` branch
+
+#### All-in-one script (for example version `v1.1.1`, stable commit `8eb8dce`):
+
+- Select the latest commit from `stable` as the "hotfix release candidate" for a new hotfix version release.
+- `git fetch origin stable`
+- `git checkout stable`
+- `yarn release:create-rc 1.1.1`
+  - Must be run locally from a write-access account capable of triggering CI.
+- Switch to the hotfix release branch and cherrypick the inclusion(s) from the `unstable` branch to the hotfix release.
+  - `git checkout rc/v1.1.1`
+  - `git cherry-pick {commit}`
+- Open draft PR from `rc/v1.1.1` to `stable` with the title `v1.1.1 release`.
+
+#### Manual steps (for example version `v1.1.1`, commit `8eb8dce`):
+
+- Select the latest commit from `stable` as the "hotfix release candidate" for a new hotfix release.
+- Checkout `stable` branch
+  - `git checkout stable`
+- Create a new release branch `rc/v1.1.1` at commit `8eb8dce`
+  - `git checkout -b rc/v1.1.1 8eb8dce`
+- Set monorepo version to `v.1.1.1`.
+  - `lerna version v1.1.1 --no-git-tag-version --force-publish --yes`
+- Commit changes
+  - `git commit -am "v1.1.1"`
+  - `git push origin rc/v1.1.1`
+Open draft PR from `rc/v1.1.1` to `stable` with the title `v1.1.1 release`.
+
+### 2. Tag release candidate
+
+Tagging a release candidate will trigger CI to publish to NPM, dockerhub, and Github releases.
+
+#### All-in-one script (for example version `v1.1.1`, commit `f3df9f8`):
+
+- Select the latest commit from `rc/v1.1.1` to tag and publish.
+- `yarn release:tag-rc 1.1.1`
+  - Must be run locally from a write-access account capable of triggering CI.
+
+#### Manual steps (for example version `v1.1.1`, commit `f3df9f8`):
+
+- Tag latest commit as `v1.1.1-rc.0` with an annotated tag, and push the tag.
+  - `git tag -am "v1.1.1-rc.0" v1.1.1-rc.0`
+  - `git push origin v1.1.1-rc.0`
+
+Continue following the "test release candidate" and "merge release candidate" sections. Testing window may be modified depending on the severity of the bug fixed.
 
 ## Dev release
 
@@ -185,10 +234,9 @@ Have someone else review the release notes and then edit the release.
 
 The release should be announced on the following social channels:
 
-- Email: with Mailchimp.
-- Discord: Use the #lodestar-announcements channel. Tag @everyone and ensure it is published to all downstream channels.
-- Twitter: Short and sweet in a single tweet with twitter.com/lodestar_eth
-- Reddit: TODO: get Lodestar account.
+- Discord: Use the #lodestar-announcements channel. Ensure it is published to all downstream channels
+- Twitter: Short and sweet in a single tweet or thread with twitter.com/lodestar_eth
+- Blog post (if necessary): To outline specific changes that require additional context for users
 
 # Release Manager Checklist
 This section is to guide the Release Manager tasked with the next version release to ensure all items have been completed.

docker/grafana/Dockerfile

@@ -1,7 +1,7 @@
 # syntax=docker/dockerfile:1.4
 
 # Same version as our ansible deployments, to minimize the diff in the dashboard on export
-FROM grafana/grafana:8.5.20
+FROM grafana/grafana:8.5.22
 
 # Datasource URL is configured with ENV variables
 COPY datasource.yml /etc/grafana/provisioning/datasources/datasource.yml

docs/install/source.md

@@ -7,6 +7,7 @@ Make sure to have [Yarn installed](https://classic.yarnpkg.com/en/docs/install).
 <!-- prettier-ignore-start -->
 !!! info
     NodeJS versions older than the current LTS are not supported by Lodestar. We recommend running the latest Node LTS.
+    It is important to make sure the NodeJS version is not changed after reboot by setting a default `nvm alias default <version> && nvm use default`.
 
 !!! note
     Node Version Manager (NVM) will only install NodeJS for use with the active user. If you intend on setting up Lodestar to run under another user, we recommend using [Nodesource's source for NodeJS](https://github.com/nodesource/distributions/blob/master/README.md#installation-instructions) so you can install NodeJS globally.