$ git rebase -i master (there will probably be conflicts)
$ git rebase -i master (there will probably be conflicts)
$ git push
$ git push
```
```
### How can I modify ethereumjs-vm-sc and test the changes at `solidity-coverage`?
### How can I modify ethereumjs-vm-sc and test the changes at `solidity-coverage`?
Since `solidity-coverage@0.1.10`, ethereumjs-vm-sc is an independent dev dependency,
Since `solidity-coverage@0.1.10`, ethereumjs-vm-sc is an independent dev dependency,
required by the coverage unit tests. The new testrpc has a separate webpacked copy. The simplest
required by the coverage unit tests. The new testrpc has a separate webpacked copy. The simplest
thing to do is open a branch at `solidity-coverage` and develop directly on the `vm` dep.
thing to do is open a branch at `solidity-coverage` and develop directly on the `vm` dep.
When you're satisfied that tests pass with your changes, copy your work over to the `ethereumjs-vm-sc` repo itself.
When you're satisfied that tests pass with your changes, copy your work over to the `ethereumjs-vm-sc` repo itself.
In `test/util/vm.js` the `results` object passed back by `vm.runTx` at [callMethod](https://github.com/sc-forks/solidity-coverage/blob/master/test/util/vm.js#L120)
In `test/util/vm.js` the `results` object passed back by `vm.runTx` at [callMethod](https://github.com/sc-forks/solidity-coverage/blob/master/test/util/vm.js#L120)
also contains things like the runState and the logs: ex: `results.vm.runState.logs`.
also contains things like the runState and the logs: ex: `results.vm.runState.logs`.
@ -57,18 +57,22 @@ also contains things like the runState and the logs: ex: `results.vm.runState.lo
+ follow the `testrpc-sc` publication steps above.
+ follow the `testrpc-sc` publication steps above.
There's no reason to worry about changing ethereumjs-vm-sc at master. If that affects anyone (unlikely)
There's no reason to worry about changing ethereumjs-vm-sc at master. If that affects anyone (unlikely)
they have safe harbour at any solidity-coverage installation @0.1.9 and up. They can update.
they have safe harbour at any solidity-coverage installation @0.1.9 and up. They can update.
### E2E Testing
### E2E Testing
[sc-forks/zeppelin-solidity](https://github.com/sc-forks/zeppelin-solidity) has been configured to
[sc-forks/zeppelin-solidity](https://github.com/sc-forks/zeppelin-solidity) has been configured to
serve as a simple pre-publication E2E test. By default the package pulls solidity-coverage from the repo's master branch.
serve as a simple pre-publication E2E test. By default the package pulls solidity-coverage from the repo's master branch.
You can trigger a [CI build](https://travis-ci.org/sc-forks/zeppelin-solidity) and [Coveralls report](https://coveralls.io/github/sc-forks/zeppelin-solidity) by running:
You can trigger a [CI build](https://travis-ci.org/sc-forks/zeppelin-solidity) and [Coveralls report](https://coveralls.io/github/sc-forks/zeppelin-solidity) by running:
```
```
$ npm run ci
$ npm run ci
```
```
### solidity-parser-sc
We also publish `solidity-parser-sc` because `consensys/solidity-parser` in its .pegjs form has been
left to die in the wild, unloved by all. Publish at the publish branch by running `npm version patch`, `npm publish`.