You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add a CI workflow that builds and runs unit tests on each pull request. TrustEVM is somewhat of a "monorepo" -- it contains multiple projects that are built independently of each other. To start with, we should build and run unit tests for the following three components (anyone feel free to chime in with more that are good in the initial scope). What we don't want in this initial CI scope is a full integration test that deploys all the components, stands up a chain, etc. That might be a good thing to have (eventually) but this ticket is not it.
The TrustEVM node
This ought to be buildable with effectively a cmake && make in the root directory. Exact dependencies required are unknown to me (I believe it's expected to compile on ubuntu 20 at least? There is no README yet making stuff like this clear). Also unknown to me if there are any unit tests.
Contract & Contract Unit Tests
The contract is in contract/ and needs to be built with cdt, and the unit tests are in contract/tests which use the Native Contract Unit Tester. These are two separate cmake projects and be aware the tests assume where the contract build directory was placed in. Most likely this should leverage the same pattern as eos-system-contracts to fetch cdt & leap-dev.deb.
Gateway Proxy & Tests
This is in peripherals/gateway_proxy. The gateway proxy "driver" is Javascript requiring node16(+?) & nginx, but the tests are in C++ and require C++20 & boost 1.75+. Even Ubuntu 22.10 is still stuck on boost 1.74 so Ubuntu will not be usable here unless you build boost.
It's possible this all ends up as one workflow with a bunch of jobs. Or separate workflows for each component. Or even one root workflow activated on a PR that then calls other separate "reusable" workflows for each project. Left to the implementer to decide best approach.
Due to the repo being private, and the reportedly long build and/or test times, we may want to consider using ENF runners until the repo is public. However, the ENF runner fleet has stringent maximum run times (lowtier being the longest at 60 minutes) so we may need adjustments to the fleet.
kj4ezj
changed the title
basic CI that builds and unit tests various components on pull request
CI to Build and Unit Test Various Components on Pull Requests
Dec 7, 2022
kj4ezj
added
the
CICD
Continuous integration, continuous deployment - build and test system
label
Dec 22, 2022
Add a CI workflow that builds and runs unit tests on each pull request. TrustEVM is somewhat of a "monorepo" -- it contains multiple projects that are built independently of each other. To start with, we should build and run unit tests for the following three components (anyone feel free to chime in with more that are good in the initial scope). What we don't want in this initial CI scope is a full integration test that deploys all the components, stands up a chain, etc. That might be a good thing to have (eventually) but this ticket is not it.
This ought to be buildable with effectively a
cmake && make
in the root directory. Exact dependencies required are unknown to me (I believe it's expected to compile on ubuntu 20 at least? There is no README yet making stuff like this clear). Also unknown to me if there are any unit tests.The contract is in
contract/
and needs to be built with cdt, and the unit tests are incontract/tests
which use the Native Contract Unit Tester. These are two separate cmake projects and be aware the tests assume where the contract build directory was placed in. Most likely this should leverage the same pattern as eos-system-contracts to fetch cdt & leap-dev.deb.This is in
peripherals/gateway_proxy
. The gateway proxy "driver" is Javascript requiring node16(+?) & nginx, but the tests are in C++ and require C++20 & boost 1.75+. Even Ubuntu 22.10 is still stuck on boost 1.74 so Ubuntu will not be usable here unless you build boost.It's possible this all ends up as one workflow with a bunch of jobs. Or separate workflows for each component. Or even one root workflow activated on a PR that then calls other separate "reusable" workflows for each project. Left to the implementer to decide best approach.
Due to the repo being private, and the reportedly long build and/or test times, we may want to consider using ENF runners until the repo is public. However, the ENF runner fleet has stringent maximum run times (
lowtier
being the longest at 60 minutes) so we may need adjustments to the fleet.See Also
.gitignore
.gitignore
-Deosio_DIR
cmake
Flag from Contract Teststests/leap/nodeos_trust_evm_test.py
to CIThe text was updated successfully, but these errors were encountered: