Hardhat-deploy: demande de fonctionnalité : autoriser les déploiements depuis le réseau principal sur un casque en mode fork

Créé le 19 nov. 2020  ·  10Commentaires  ·  Source: wighawag/hardhat-deploy

Ce serait cool si wait ethers.getContract("Bar") lorsqu'il est exécuté en mode hardhat forking, ferait savoir à hardhat-deploy que --network hardhat peut en fait également prendre en considération les déploiements / à partir de n'importe quel réseau configuré dans forking

Référencement de ce problème https://github.com/wighawag/hardhat-deploy-ethers/issues/6

enhancement

Tous les 10 commentaires

implémenté dans la 0.7.0-beta.29
via hardhat node --fork ... --fork-deployments <networkName>

Copie de notre chat pour référence :

Est-ce exclusif au réseau que vous passez avec --fork-deployments ? Idéalement pour moi ça ferait ça :

  1. Regardez d'abord dans le dossier des déploiements de fork-deployments - si le contrat n'y est pas
  2. Regardez dans —dossier de déploiements réseau en second lieu

De cette façon, les tests peuvent mélanger des instances de contrat fourchues du réseau principal et des instances fictives que vous ne voudrez peut-être déployer que sur un réseau de casques.

cela fonctionne en copiant les déploiements de la chaîne dans localhost
ainsi votre script de déploiement peut décider de remplacer le déploiement s'il le souhaite

  1. ah ok cool. comment sait-il sur quel réseau copier les déploiements ? Analyse-t-il le forking.url ?

  2. J'utilise hardhat network in-memory forking et je n'ai pas d'instance de hardhat node en cours d'exécution pendant mes tests. Cela fonctionne-t-il également pour les tests utilisant le fork sur un réseau de casques en mémoire ?

ha non, bon point, ce n'est qu'un paramètre pour la tâche de nœud.
Je devrais pouvoir l'ajouter à la tâche de test. réouverture

re 1. : l'argument du param est le nom du réseau à partir duquel copier

En fait, @gitpusha avez-vous un exemple de
actuellement avec un réseau en mémoire, il n'y a pas de possibilité d'avoir des informations de contrat pré-déployées
Je pourrais peut-être ajouter un paramètre similaire, mais je dois réfléchir davantage

en fait, vous devriez pouvoir utiliser la configuration des déploiements externes :

quelque chose comme :

casque.config.js

module.exports = {
 ...
  external: {
    deployments: {
      hardhat: ['deployments/mainnet'],
    },
  },
}

en fait, vous devriez pouvoir utiliser la configuration des déploiements externes

Ce serait gentil.

hardhat: ['deployments/mainnet']

L'outil comprend-il que sur hardhat in devrait alors examiner à la fois deployments/mainnet ainsi que deployments/hardhat ? Si oui, quels déploiements sont prioritaires ? Je voudrais que le deployments/mainnet ait la priorité s'il y a des chevauchements entre les contrats, puisque je l'ai configuré explicitement.

Aussi, le répertoire deployments/hardhat sera-t-il pris en compte par défaut ?

Voici un exemple de dépôt .

Je ne suis pas sûr de l'utilité de cette fonctionnalité, car vous pouvez toujours utiliser

await hre.ethers.getContractAt(abi, address)

dans forkmode place pour accéder aux instances déployées à partir d'un réseau spécifique.

Donc c'est vraiment juste un bon à avoir.

J'ai essayé la suggestion que j'ai postée ci-dessus et cela semble bien fonctionner.
Les déploiements spécifiés dans external n'auront pas la priorité, mais cela ne devrait pas être un problème car le nœud par défaut réinitialise le contrat dans les déploiements/le casque et donc à moins que vous ne forciez le redéploiement du contrat déjà déployé, vous obtiendrez celui de déploiements/mainnet

Je vais fermer le sujet mais si vous avez un problème n'hésitez pas à rouvrir

Cette page vous a été utile?
0 / 5 - 0 notes