The `rocksdb` version shipped with distributions is typically old and
therefore often lacks features we use - it also doesn't match the one
assumed by nim-rocksdb leading to ABI mismatch risks.
Instead of depending on the system rocksdb, we'll now use the rocksdb
version assumed by nim-rocksdb and locked in its vendor folder by always
building it together with nimbus.
This avoids the problem of unknown rocksdb versions at a (small) cost to
build time.
CI caching and full windows support for building from source [remains
TODO](https://github.com/status-im/nim-rocksdb/issues/44).
* Implement engine_getClientVersionV1
* full git revision string
* Limit GitRevisionString to 8 chars
* Fixes
* Debug windows CI
* debug windows ci
* produce git revision using -C
* try not to delete .git folder in windows ci
* Harden GitRevision procuration
* Add double quotes to git -C param
* Escape sourcePath
* Remove double quotes from git -C param
With this schedule the new fluffy Docker build should be available
before public portal-hive tests are run. Else, we get an extra day
of delay to see the results of the current latest.
* Bump nimbus-eth2 and fix beacon LC related changes
* Disable local_testnet test in CI
Latest version is no longer compatible with the old nightlies that are being downloaded for the test
Two unresolved items currently:
- Three tests that are temporarily disabled as they fail in the
macro_assembler code, which seems to be due to an ambigious
identifier Stop (Ops and chronos ServerCommand enum).
- i386 CI disabled as it fails at Nim compilation already. Failed
tests where already ignored for this target.
* Cosmetics, update logger `topics`
* Clean up sync/start methods in nimbus
why:
* The `protocols` list selects served (as opposed to sync) protocols only.
* The `SyncMode.Default` object is allocated with the other possible sync
mode objects.
* Add snap service stub to `nimbus`
* Provide full set of snap response handler stubs
* Bicarb for the latest CI hiccup
why:
Might be a change in the CI engine for MacOS.
* Change Light client proxy naming to verified proxy naming in code
* Rename the lc_proxy files to the verified proxy naming
* Update to the verified proxy name in the docs
* dist: precompiled binaries and Docker images
The builds are reproducible, the binaries are portable and statically link librocksdb.
This took some patching. Upstream PR: https://github.com/facebook/rocksdb/pull/9752
32-bit ARM is missing as a target because two different GCC versions
fail with an ICE when trying to cross-compile RocksDB. Using Clang
instead is too much trouble for a platform that nobody should be using
anyway.
(Clang doesn't come with its own target headers and libraries, can't be
easily convinced to use the ones from GCC, so it needs an fs image from
a 32-bit ARM distro - at which point I stopped caring).
* CI: disable reproducibility test
* Redesign of BaseVMState descriptor
why:
BaseVMState provides an environment for executing transactions. The
current descriptor also provides data that cannot generally be known
within the execution environment, e.g. the total gasUsed which is
available not before after all transactions have finished.
Also, the BaseVMState constructor has been replaced by a constructor
that does not need pre-initialised input of the account database.
also:
Previous constructor and some fields are provided with a deprecated
annotation (producing a lot of noise.)
* Replace legacy directives in production sources
* Replace legacy directives in unit test sources
* fix CI (missing premix update)
* Remove legacy directives
* chase CI problem
* rebased
* Re-introduce 'AccountsCache' constructor optimisation for 'BaseVmState' re-initialisation
why:
Constructing a new 'AccountsCache' descriptor can be avoided sometimes
when the current state root is properly positioned already. Such a
feature existed already as the update function 'initStateDB()' for the
'BaseChanDB' where the accounts cache was linked into this desctiptor.
The function 'initStateDB()' was removed and re-implemented into the
'BaseVmState' constructor without optimisation. The old version was of
restricted use as a wrong accounts cache state would unconditionally
throw an exception rather than conceptually ask for a remedy.
The optimised 'BaseVmState' re-initialisation has been implemented for
the 'persistBlocks()' function.
also:
moved some test helpers to 'test/replay' folder
* Remove unused & undocumented fields from Chain descriptor
why:
Reduces attack surface in general & improves reading the code.
* Provide PoA voting header generator
why:
Handy for hive/smoke test
details:
Header generator is a re-implementation of the generator previously
used for the canonical reference tests.
* try fixing ci out-of-mem condition
why:
for some reason, the ci began behaving like a real win7/i386 machine
where gcc is limited to 64k optimiser space
* fix comments, typos ..
With Whisper support gone, the wrappers cannot be built. More detail in the
patch that removes the wrappers.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
Reverts part of commit 2539bd9 while keeping the intention of it:
To avoid duplicate CI runs when making and updating a PR.
Disabling `push` means we cannot push to a branch and see the CI results
directly without making a PR, which some of us use. There are many situations
where this is useful, and "[WIP]" PRs are not appropriate for all.
Disabling `pull_request` has a similar effect, removing duplicate CI.
It is known that `pull_request` _is_ needed when a third party sends a
PR (because it's not committed to the repo yet). But this is rare at the
moment, and there's a workaround: A committer can push the third party change
to a branch, triggering CI.
So re-enable `push`, disable `pull_request`, and we'll see if the latter
missing causes problems in practice. Won't know until we try it.
Note: This might be interim until `workflow_dispatch` is working better.
Perhaps that needs more configuration. Currently, `workflow_dispatch` is kind
of useless for CI tests, because it doesn't result in any CI indicator
associated with a commit or branch. Even the actions page doesn't show the
name of the branch, just a less-than-useful generic "CI" for these actions.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
Files underneath `hive_integration` are not used to build anything,
so don't trigger CI when these files change.
Most of them are manually copied into Hive `hive/clients/nimbus`.
The rest are instructions and a standalone helper program not used by CI.
Signed-off-by: Jamie Lokier <jamie@shareable.org>
The CI takes a long time (sometimes hours) and shouldn't hold up
documentation-only commits. We may also find CI for other changes starts
faster, if we're not using up as many credits. When we process documentation
into something nicer (like `nimbus.guide`) we'll need to revisit this.
Syntax from [example ignoring paths](https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#example-ignoring-paths).
Signed-off-by: Jamie Lokier <jamie@shareable.org>
why:
vm2 enabled by ENABLE_VM2=1 behaves as vm without ENABLE_EVMC=1 until
it doesn't in some future fatch set. this leaves some wiggle room
to work on a vm copy without degrading the original implementation.
details:
+ additional make flag ENABLE_VM2=1 (or ENABLE_VM2=0 to explicitely disable)
+ when both flags ENABLE_EVMC=1 and ENABLE_VM2=1 are present, the former
flag ENABLE_EVMC=1 takes precedence, this is implemented at the NIM
compiler level for -d:evmc_enabled and -d:vm2_enabled
andri lim
Jacek Sieka
tersec
Kim De Mey
Jordan Hrycaj
KonradStaniec
Nikolay Mitev
Ștefan Talpalaru
Jamie Lokier