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

lodestar/cli: overhaul util/version and gitdata #2958

Merged
merged 15 commits into from
Aug 17, 2021
Merged

Conversation

q9f
Copy link
Contributor

@q9f q9f commented Aug 13, 2021

Motivation

Allow for more information in the version string; also clean up util/version and gitdata and reduce duplicated code.

Description

  • Refactored git data file code and removed some duplicated structures and unused code.
  • util/gitData/* no longer generates version strings, it just handles all version information (semver, branch, commit, ...)
  • util/version now generates a proper version string from available data (either from json or from git)
    • example: v0.28.1/q9-yarn-semver/+14/b0616bfd (unstable) (semver/branch/number of commits since last release/commit hash/release track if any)
  • util/version now defines a default release track (stability), for now: alpha
  • cli/cli improved top banner of the --help output and also used same information for --version
~/.opt/chainsafe/lodestar q9-yarn-semver
❯ ./lodestar --version
🌟 Lodestar: TypeScript Implementation of the Ethereum 2.0 Beacon Chain.
  * Version: v0.28.1/q9-yarn-semver/+14/b0616bfd (unstable)
  * by ChainSafe Systems, 2018-2021

~/.opt/chainsafe/lodestar q9-yarn-semver
❯ ./lodestar --help   
🌟 Lodestar: TypeScript Implementation of the Ethereum 2.0 Beacon Chain.
  * Version: v0.28.1/q9-yarn-semver/+14/b0616bfd (unstable)
  * by ChainSafe Systems, 2018-2021

Commands:
  beacon             Run a beacon chain node
  validator          Run one or multiple validator clients
  account <command>  Utilities for generating and managing Ethereum 2.0 accounts
  init               Initialize Lodestar directories and files necessary to run
                     a beacon chain node. This step is not required, and should
                     only be used to prepare special configurations
  dev                Quickly bootstrap a beacon node and multiple validators.
                     Use for development and testing

Options:
      --rootDir     Lodestar root directory                             [string]
      --network     Name of the Eth2 chain network to join
           [string] [choices: "mainnet", "pyrmont", "prater", "altair-devnet-3"]
                                                            [default: "mainnet"]
      --preset      Specifies the default eth2 spec type
                   [string] [choices: "mainnet", "minimal"] [default: "mainnet"]
      --paramsFile  Network configuration file
                                        [string] [default: $rootDir/config.yaml]
  -h, --help        Show help                                          [boolean]
  -v, --version     Show version number                                [boolean]

📖 For more information, check the CLI reference:
  * https://chainsafe.github.io/lodestar/reference/cli

✍️ Give feedback and report issues on GitHub:
  * https://github.com/ChainSafe/lodestar

The code also handles the logic of releases and dirty/nightly builds. A release version string is simply v0.28.1 (alpha) whereas dirty builds have all info v0.28.1/q9-yarn-semver/+14/b0616bfd (unstable). If git data is not available, it will fall back to lerna.json/package.json and just use 0.28.1.

This is my first typescript contribution. Review with care. 🙏🏼

Fixes #2950

@CLAassistant
Copy link

CLAassistant commented Aug 13, 2021

CLA assistant check
All committers have signed the CLA.

@github-actions github-actions bot added the CLI label Aug 13, 2021
@codeclimate
Copy link

codeclimate bot commented Aug 13, 2021

Code Climate has analyzed commit 9a54076 and detected 0 issues on this pull request.

View more on Code Climate.

@lgtm-com
Copy link

lgtm-com bot commented Aug 13, 2021

This pull request introduces 3 alerts when merging d43112e into 80c248b - view on LGTM.com

new alerts:

  • 2 for Invocation of non-function
  • 1 for Unused variable, import, function or class

@q9f q9f requested a review from dapplion August 16, 2021 11:23
@q9f q9f marked this pull request as ready for review August 16, 2021 11:23
@q9f
Copy link
Contributor Author

q9f commented Aug 16, 2021

I would appreciate if we can make a test point release (v0.28.2) if this is good to go.

@github-actions
Copy link
Contributor

github-actions bot commented Aug 16, 2021

Performance Report

✔️ no performance regression detected

Full benchmark results
Benchmark suite Current: 56bce48 Previous: c664482 Ratio
getCommitteeAssignments - req 1000 vs - 250000 vc 7.6097 ms/op 7.9364 ms/op 0.96
processBlock altair 250000 vs - 7PWei - maxed ops 448.28 ms/op 418.20 ms/op 1.07
processBlock altair 250000 vs - 7PWei - average 173.55 ms/op 144.77 ms/op 1.20
epoch altair - 250000 vs - 7PWei - processInactivityUpdates 2.4972 s/op 2.3585 s/op 1.06
epoch altair - 250000 vs - 7PWei - processRewardsAndPenalties 1.1121 s/op 1.0776 s/op 1.03
epoch altair - 250000 vs - 7PWei - processParticipationFlagUpdates 464.95 ms/op 437.87 ms/op 1.06
processBlock phase0 250000 vs - 7PWei - maxed ops 206.86 ms/op 184.29 ms/op 1.12
processBlock phase0 250000 vs - 7PWei - average 29.164 ms/op 24.133 ms/op 1.21
epoch phase0 - 250000 vs - 7PWei - beforeProcessEpoch 1.6319 s/op 1.5556 s/op 1.05
epoch phase0 - 250000 vs - 7PWei - processRewardsAndPenalties 718.14 ms/op 656.81 ms/op 1.09
epoch phase0 - 250000 vs - 7PWei - processEffectiveBalanceUpdates 119.06 ms/op 106.76 ms/op 1.12
getAttestationDeltas - 250000 vs - 7PWei 114.68 ms/op 129.11 ms/op 0.89
processSlots - 250000 vs - 7PWei - 32 empty slots 3.2020 s/op 3.1690 s/op 1.01
shuffle list - 16384 els 15.508 ms/op 24.883 ms/op 0.62
shuffle list - 250000 els 221.03 ms/op 365.94 ms/op 0.60
getPubkeys - persistent - req 1000 vs - 250000 vc 17.630 us/op 15.847 us/op 1.11
BLS verify - blst-native 2.0893 ms/op 1.8577 ms/op 1.12
BLS verifyMultipleSignatures 3 - blst-native 4.2726 ms/op 3.8112 ms/op 1.12
BLS verifyMultipleSignatures 8 - blst-native 8.9437 ms/op 8.2021 ms/op 1.09
BLS verifyMultipleSignatures 32 - blst-native 32.862 ms/op 29.852 ms/op 1.10
BLS aggregatePubkeys 32 - blst-native 45.171 us/op 40.787 us/op 1.11
BLS aggregatePubkeys 128 - blst-native 170.96 us/op 155.89 us/op 1.10
getAttestationsForBlock 242.22 ms/op 222.66 ms/op 1.09
validate gossip signedAggregateAndProof - struct 8.2628 ms/op 4.5075 ms/op 1.83
validate gossip signedAggregateAndProof - treeBacked 5.1218 ms/op 4.4777 ms/op 1.14
validate gossip attestation - struct 4.8099 ms/op 4.4260 ms/op 1.09
validate gossip attestation - treeBacked 2.6174 ms/op 2.2206 ms/op 1.18

by benchmarkbot/action

wemeetagain
wemeetagain previously approved these changes Aug 16, 2021
Copy link
Member

@wemeetagain wemeetagain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

I tested locally against this branch and with a mock v0.28.2 release.
This shouldn't effect our npm releases, it will just make lodestar --version more accurate.

@q9f
Copy link
Contributor Author

q9f commented Aug 17, 2021

Ok, fixed the linter issues, this should be good to go.

wemeetagain
wemeetagain previously approved these changes Aug 17, 2021
@q9f
Copy link
Contributor Author

q9f commented Aug 17, 2021

Sorry, fixed one minor logic issue. Now it's good to go.

Copy link
Contributor

@dapplion dapplion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great! Much more accurate and polished than before.

The purpose of the gitData file was to distribute the commit at which that version is built to NPM. Since (package.json).version only includes the semver, that information is not available and you need to go to git to check the commit associated to that tag. That has been very useful for nightly releases since we show the "version" tag (version + branch + commit) in the metrics panel, so very quickly you can check what that node is running from Grafana.

Do you think we achieve a similar behavior is more clean and polished way?

@q9f
Copy link
Contributor Author

q9f commented Aug 17, 2021

Thanks for the review. The logic around gitData was not changed and should be still available. Do you mean, we should expose branch and commit on the metrics even though it's usually a tag release? Metrics is the only place where I changed it for simplicity but happy to add back more details.

@dapplion
Copy link
Contributor

@q9f Another better option would be to use nightly versioning as 0.27.1-dev.a6b280 instead of what we have right now that's just a counter 0.27.1-dev.31 👍

@dapplion dapplion merged commit b9a7e6a into master Aug 17, 2021
@dapplion dapplion deleted the q9-yarn-semver branch August 17, 2021 17:35
@q9f
Copy link
Contributor Author

q9f commented Aug 18, 2021

@q9f Another better option would be to use nightly versioning as 0.27.1-dev.a6b280 instead of what we have right now that's just a counter 0.27.1-dev.31 +1

I just checked, the nighly release version is 0.28.2-dev.3+022659b5fc0 according to Github actions (appending the --canary git sha option) but the NPM registry just truncates everything after the + to strict (?) semver and it just remains 0.28.2-dev.3. I found this: lerna/lerna#1893

Association with the current NPM versions is very hard. If the published version is foo@0.1.5-alpha.124, I have to count 124 commits up from 0.1.4 or go through CI logs to figure out which commit that version is tied to. If it were foo@0.1.5-alpha.124.3d6bee55 or foo@0.1.5-alpha.3d6bee55 it would be much easier.

It looks like Lerna is publishing with the +${sha} suffix, but it seems NPM is stripping it out. If that's the case, why is this format not configurable?

At first glance, there seems no easy way to force lerna to do that properly.

@dapplion
Copy link
Contributor

@q9f Another better option would be to use nightly versioning as 0.27.1-dev.a6b280 instead of what we have right now that's just a counter 0.27.1-dev.31 +1

I just checked, the nighly release version is 0.28.2-dev.3+022659b5fc0 according to Github actions (appending the --canary git sha option) but the NPM registry just truncates everything after the + to strict (?) semver and it just remains 0.28.2-dev.3. I found this: lerna/lerna#1893

Association with the current NPM versions is very hard. If the published version is foo@0.1.5-alpha.124, I have to count 124 commits up from 0.1.4 or go through CI logs to figure out which commit that version is tied to. If it were foo@0.1.5-alpha.124.3d6bee55 or foo@0.1.5-alpha.3d6bee55 it would be much easier.
It looks like Lerna is publishing with the +${sha} suffix, but it seems NPM is stripping it out. If that's the case, why is this format not configurable?

At first glance, there seems no easy way to force lerna to do that properly.

What if we write our own version format? Not use any counter at all and only the commit hash:

0.28.2-dev.022659b5fc0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

lodestar --version should indicate release track
4 participants