Skip to content
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

Cannot find generated artifacts #573

Closed
wighawag opened this issue Nov 17, 2020 · 18 comments
Closed

Cannot find generated artifacts #573

wighawag opened this issue Nov 17, 2020 · 18 comments

Comments

@wighawag
Copy link

I am using hardhat-deploy with solidity-coverage so there might be some incompatibilities but cannot find any obvious one

The issue I have is that there seems to be no generated artifacts in the temp folder, even though the .coverage_cache contains solidity-files-cache.json

I commented the line that delete the temp folder and after execution of hardhat coverage the folder exist but is empty.

Any idea ?

@cgewecke
Copy link
Member

Hi @wighawag,

Do you have an example I could try to reproduce with?

There is a basic e2e test at https://github.com/sc-forks/hardhat-e2e that we're using in CI here.

To run solidity-coverage with it you would

git clone https://github.com/sc-forks/hardhat-e2e.git
cd hardhat-e2e
npm install
npm install --save-dev solidity-coverage
npx hardhat coverage

@wighawag
Copy link
Author

I have this repo (branch: solidity-coverage) : https://github.com/wighawag/template-ethereum-contracts/tree/solidity-coverage

@cgewecke
Copy link
Member

It works when running...

npx hardhat coverage --temp artifacts

--temp specifies an alternate temporary folder to store coverage-instrumented artifacts in.

Does the deploy plugin also run the compile task?


Screen Shot 2020-11-17 at 2 32 56 PM

@cgewecke cgewecke added Hardhat and removed Hardhat labels Nov 17, 2020
@wighawag
Copy link
Author

wighawag commented Nov 17, 2020

interesting

It seems that when not using --temp artifacts, the temp artifacts do not contains any files and hardhat hre.artifacts.readArtifact works because it have the path of artifact set before solidity-coverage is executed
while the plugin hardhat-deploy use config.paths.artifacts to get the artifacts

@wighawag
Copy link
Author

I guess the artifacts are suposed to be generated in the temp folder , right ?

@wighawag
Copy link
Author

note that generating temp in the default artifacts folder (but saving the cache in a different folder than the default cache folder) will make hardhat caching fails as it will keep using soldity-coverage artifacts unless changes to file happen

@cgewecke
Copy link
Member

cgewecke commented Nov 17, 2020

It seems that when not using --temp artifacts, the temp artifacts do not contains any files and hardhat hre.artifacts.readArtifact works because it have the path of artifact set before solidity-coverage is executed
while the plugin hardhat-deploy use config.paths.artifacts to get the artifacts

Yes I think you're right that something is going wrong with the sequence that things are read in.

solidity-coverage resets the path values (including cache) here:

config.paths.artifacts = tempArtifactsDir;
config.paths.cache = nomiclabsUtils.tempCacheDir(config);

@wighawag
Copy link
Author

yes, hardhat-deploy read the path for artifacts from these newly update paths but because there is no files there it fails to get them (unless --temp artifacts
on the other hand anything based on hre.artifacts.readArtifact will read from the path originally set in hardhat.config so no temp folder
And I guess solidity-coverage expect that hardhat will write the artifacts in config.paths.artifacts but hardhat seems to already have decided where it is based on the value set in hardhat.config.

So hardhat should allow plugin to update the path, either by having hardhat read config.paths each time or by having an api for the plugins to update it

@cgewecke
Copy link
Member

So hardhat should allow plugin to update the path, either by having hardhat read config.paths each time or by having an api for the plugins to update it

Mmm, I think under normal circumstances it does allow this and the problem is coming from plugin interaction. Normally the temporary artifacts are saved to the temp folder and HH reads from them correctly.

@wighawag
Copy link
Author

Without hardhat-deploy I can see that the temp artifact folder are empty too.
I think what is happening is that solidity-coverage overwrite the artifacts in the artfiacts folder, not in the temp folder
and it works only because hre.artifacts.readArtifacts also read from there

@cgewecke
Copy link
Member

Oh I see. You might be right that this is hre.artifacts.readArtifact specific. The e2e test I have and other testing I've done is using artifacts.require via the truffle-v5 plugin.

@wighawag
Copy link
Author

I guess artifacts.require use hre.artifacts.readArtifacts hence why it works

see here where the artifacts is set at env construction time : https://github.com/nomiclabs/hardhat/blob/6ffb8baf0ede8c8c73b502bba826b0f8196604b2/packages/hardhat-core/src/internal/core/runtime-environment.ts#L77

@cgewecke
Copy link
Member

@wighawag To be clear, you don't set the paths anywhere in your code? Only read?

@wighawag
Copy link
Author

yes only read

@cgewecke
Copy link
Member

Ah ok ok I just re-ran my e2e an now I see exactly what you're saying. Something's seriously wrong.

Thanks for helping with all of this, sorry.

@wighawag
Copy link
Author

No problem, glad to be of help. solidity-coverage is a great tool :)

@cgewecke
Copy link
Member

cgewecke commented Dec 3, 2020

@wighawag This should be fixed with 0.7.13 in combination with Hardhat 2.0.4. There's no longer any need to use the --temp flag and solidity-coverage has stopped trying to modify the paths artifacts & cache values.

Have also added your a fork of your ethereum-template-contracts project as a smoke-test in CI here and everything seems to work as expected.

Just lmk if you see any further problems on your side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants