Add unit tests for the contract tracking `embark-deploy-tracker` package.
`trackingFunctions` was refactored in a way to make it more testable and now performs tracker file IO on demand, as opposed to being executed for each contract deploy. Additionally, removed any synchronous file IO in favour of their asynchronous counterparts.
Added special case for config contract-level tracking:
when `contract.track === false` in contracts config, contracts are deployed, then the config is changed `contract.track` is truthy, a special use case is presented, and the chains.json file is updated accordingly.
Prior to this PR (including with v4), Embark would hang on a deployment error.
After this PR, Embark continues it’s run routine despite a contract deployment error, and reports the error to the user in the console appropriately.
NOTE: this branch is based on `refactor/add-contract-tracking` (which would land in https://github.com/embark-framework/embark/pull/1743). If #1743 lands (will be merged in to `refactor_5_0_0`), I will rebase this branch on top of `refactor_5_0_0`.
Add back contract tracking to the refactored code. Deployment checks are added as plugins to the `embark-deployment` module.
Adds ability to track if a contract has already been deployed, and skips deployment if so.
Updates error handling flow for deployment process.
Adds a contract class to the `embark-contracts-manager`, to add a `log` function for the contract. This `log` function can be called from any module that has the contract instance.
Adds TS interfaces for contracts configuration.
Handles the following cases:
1. Contract already deployed
2. Contract not deployed
3. Contract is configured with `{track: false}` (deploy if not deployed, and don't track)
5. Contract is configured with an `address` in the config
6. `trackContracts` set to `false` from `engine` (always deploy but don't track contracts). Currently used for the tests.
7. Contract deployment produces an error
8. Interface deployment shows warning.
PR with unit tests and documenation to follow.
remove code not beloging to code runner & other core modules; disable code generator and move contract code to its own module
cleanup pipeline; start preparing for plugin based pipeline file generation
initial work to write pipeline files through an api
add action events to pipeline; generate contracts json and js files
move old pipeline to its own module; generate basic artifacts
re-add missing plugins function
add basic embarkjs provider registration
refactor embark-whisper; move whisper api; execute whisper code in console
add api to register help cmds in console; start moving hardcoded help cmds out
cleanup embark-graph
add todos
When running tests against non-simulated blockchain nodes, even for simplex
Smart Contracts, deployment transactions would exceed the block gas limit.
E.g. running `embark blockchain` in one process and `embark test --node embark`
in another, inside our demo application, will throw an error when Embark attempts
to deploy its `SimpleStorage`:
```
Compiling contracts
Compilation done
[SimpleStorage]: error deploying =SimpleStorage= due to error: Returned error: exceeds block gas limit
Error deploying contracts. Please fix errors to continue.
Error deploying contracts. Please fix errors to continue.
terminating due to error
Error deploying contracts. Please fix errors to continue.
```
The reason for that is because in https://github.com/embark-framework/embark/pull/1650, we've introduced a static
gas estimation for Smart Contract deployment that is just right below Ganache's
maximum gas limit of `6721975`, since Ganache tends to underestimate gas for
complex Smart Contracts due to its [low base fee](8ad1ab29de/lib/utils/gasEstimation.js (L33-L39)).
The static gas estimation would apply any time we're in a test context, but we
didn't take into account the case where tests are executed against nodes
other than the simulated environment.
As mentioned in the comments in the linked PR:
> If this is not spec'ed at all, I wonder what complications it could cause when
> at some point we maybe switch to not using Ganache anymore for tests, or even
> the user itself (which I think is a reasonable thing to do).
This causes the error described above because we easily reach the block gas limit
with just two Smart Contracts and Embark already deploys a few Smart Contracts for
ENS.
So basically what we want is to use the static gas estimation when we know
the node we're connecting to is Ganache. In all other cases we can rely on the
standardized gas estimation offered by the node.
In https://github.com/embark-framework/embark/pull/1119 we've introduced a feature where
users can provide an already compiled ABI for Smart Contracts so they can be used
without the need to compiling them again.
This also means that, internally, those Smart Contract object won't have any
bytecode attached to it.
Later on, in 387d33a076, we've introduced a warning
which is rendered when a Smart Contract's bytecode is too large. The check expects
a Smart Contract object to have bytecode associated to it, which will break the code
in cases where a Smart Contract has already an ABI and therefore didn't need compilation.
This commit ensures we only check a Smart Contract's bytecode when bytecode exists for
the Smart Contract in question.
