Skip to content

Use buidler's RC for compiling and testing #1071

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

Open
wants to merge 16 commits into
base: master
Choose a base branch
from

Conversation

fvictorio
Copy link

Hi! This PR upgrades Buidler (and buidler-truffle5) to the RC of the next major version. This should let you remove the need of an extra setup for your legacy contracts.

I adapted the scripts so that contracts can be compiled and tests can be executed. I haven't udpated the coverage scripts because that plugin is not adapted to the new compilation pipeline yet.

You'll see a lot of lines modified in the tests. This is because one of the changes in buidler's new compilation pipeline is that artifacts don't live in a flat structure in the artifacts directory anymore. Instead, they replicate the directory structure of the contracts. This means that now you can have contracts with the same name, without one artifact being written over the other.

But this comes with a cost: now if you have two contracts named Foo you can't do artifacts.require('Foo'), because there's no way to know which one you want. In those scenarios, you have to use the Fully Qualified Name, for example contracts/Foo.sol:Foo. When there's only one contract with that name, this is not necessary.

Most tests seem to pass with the new setup. Some of them failed, but I think it wasn't unrelated to this change (timeouts for example). But of course let me know if this indeed breaks some tests.

You surely do other things in your workflow besides compiling and running tests, and chances are they don't work with this new setup. Please let me know when that happens and I'll try to help!

Hope you enjoy it 😄

@Anyhowclick
Copy link
Contributor

Haha woah, thanks for the PR!

Loving the feature! =)

Copy link
Contributor

@ilanDoron ilanDoron left a comment

Choose a reason for hiding this comment

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

Thanks very much for this PR

its a great feature.

2 comments:

  1. file 'contracts/sol5/Token.sol' can be deleted. its code should be copied as is to "contracts/sol5/bridges/eth2Dai/mock/WethToken.sol"
  • the above will enable removing all places where it has this specific artifact used:
    'const TestToken = artifacts.require("contracts/sol6/mock/Token.sol:Token");'
    I can PR this to your code if its too much hassle.
  1. travis checks are failing due to js heap size limit reached. can this change be related to new buidler feature?

@fvictorio
Copy link
Author

I can PR this to your code if its too much hassle.

I can do it, no problem. But anyway you should be able to push to my branch if you want.

travis checks are failing due to js heap size limit reached. can this change be related to new buidler feature?

It's possible that it's using more memory than before, but it shouldn't be a big difference. Maybe I should add export NODE_OPTIONS=--max-old-space-size=4096 to the tst.sh script, like cmp.sh has?

@ilanDoron
Copy link
Contributor

ilanDoron commented Sep 22, 2020 via email

@fvictorio
Copy link
Author

fvictorio commented Sep 22, 2020

I ended up removing just the Token of Token.sol and inlining that in WethToken.sol, and then I renamed Token.sol to StandardToken.sol. I did it that way just to avoid moving a lot of stuff to WethToken. In any case, it did work to avoid having to use the FQN in the tests.

},

paths: {
sources: "./contracts/sol6",
sources: "./contracts",
tests: "./test/",
},

mocha: {
enableTimeouts: false
Copy link
Contributor

Choose a reason for hiding this comment

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

I see some tests time out now
seems this flag not working?

Copy link
Author

Choose a reason for hiding this comment

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

Apparently that option is not working anymore. That's weird because, while enableTimeouts was removed in mocha@8, buidler depends on version 7.

You can use timeout: 0 instead.

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh
I see
thanks
can u update here
it fails the CI for this PR

Copy link
Contributor

@ilanDoron ilanDoron left a comment

Choose a reason for hiding this comment

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

Timeout issue was solved
great
trying to look at the failures locally

when compiling localy I see these results:

Compiling with 0.4.18
Downloading compiler version 0.4.18
Compiled 65 contracts successfully
Compiling with 0.4.18
Compiled 1 contract successfully
Compiling with 0.4.18
Compiled 7 contracts successfully
Compiling with 0.4.18
Compiled 1 contract successfully
Compiling with 0.4.18
Compiled 1 contract successfully
Compiling with 0.4.18
Compiled 1 contract successfully
Compiling with 0.4.18
Compiled 1 contract successfully
Compiling with 0.4.18
Compiled 1 contract successfully
Compiling with 0.4.18
Compiled 1 contract successfully
Compiling with 0.4.18
Compiled 1 contract successfully
Compiling with 0.4.18
Compiled 1 contract successfully
Compiling with 0.4.18
Compiled 1 contract successfully
Compiling with 0.5.11
Downloading compiler version 0.5.11
Compiled 13 contracts successfully
Compiling with 0.5.11
Compiled 3 contracts successfully
Compiling with 0.6.6
Downloading compiler version 0.6.6
Compiled 102 contracts successfully
Compiling with 0.6.6
Compiled 1 contract successfully
Compiling with 0.6.6
Compiled 1 contract successfully
Compiling with 0.6.6
Compiled 1 contract successfully
Compiling with 0.6.6
Compiled 1 contract successfully

this expected behaviour?

@fvictorio
Copy link
Author

Oh, yeah, the output is ugly right now. It'll get better!

@ilanDoron
Copy link
Contributor

ilanDoron commented Sep 24, 2020

@fvictorio
I am running locally
seems the EVM behaviour changed a bit for assert.

4 tests that cause assert to trigger are now returning invalid opcode and not revert opcode.

we use openzeppelin expect revert code and it issues an error.
any idea about this?

@ilanDoron
Copy link
Contributor

Oh, yeah, the output is ugly right now. It'll get better!

OK
we can leave with that
:)

@fvictorio
Copy link
Author

4 tests that cause assert to trigger are now returning invalid opcode and not revert opcode.

Yes, I forgot to mention that! This changed but I think the previous behavior should be considered a bug, so changing the assertions should be fine AFAIK. @alcuadrado is this correct?

@alcuadrado
Copy link

That is correct, @fvictorio

@ilanDoron
Copy link
Contributor

ilanDoron commented Sep 24, 2020 via email

@alcuadrado
Copy link

Yes, exactly @ilanDoron. The previous behavior was a bug, which prevented you to distinguish between tx failing because of revert and invalid opcodes been executed. My bug actually 😅

@ilanDoron
Copy link
Contributor

ilanDoron commented Sep 25, 2020 via email

- keep require call for Token.sol with current convetion. to be aliged with other calls.
@ilanDoron
Copy link
Contributor

@fvictorio please see my PR to your code.
should solve the failing tests.
And also a few more updates.

@ilanDoron
Copy link
Contributor

@fvictorio
please approve here:
fvictorio#1

@fvictorio
Copy link
Author

fvictorio commented Sep 29, 2020

Hey @ilanDoron, I left a comment in that PR with respect to the yarn.lock

ilanDoron and others added 2 commits September 29, 2020 21:09
Updating tests to have correct check when expecting assertion. and reverting some changes in require statments
@ilanDoron
Copy link
Contributor

@fvictorio
I apologise
had a typo
please merge once more

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.

4 participants