-
Notifications
You must be signed in to change notification settings - Fork 13
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
Collateral onboarding docker container. #404
Conversation
make | ||
dapp create DssSpell |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This make all
only builds them, but doesn't execute
What dapp create DssSpell
actually do? Can 1+ particular spell be executed instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://github.com/makerdao/spells-mainnet#deploy refers to the make directive deploy
this directive make deploy
sadly also runs a python script that performs a bunch of verifications and at least during the developing was a blocker. Thus in order to avoid running the python script i executed the command separately.
https://github.com/makerdao/spells-mainnet/blob/d000902ad35c1eb8425db71b05b17c716bf0a66a/Makefile#L9
SO what it actually does is deploying a compiled contract.
If one has to guarantee that the collateral is onboarded via the spell, they would have to adjust the solidity code in the repository (readme there covers what to edit)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The python script contains calls to the etherscan which would fail since we run it on the fork instead
// Few blocks before WSTETH-A is taken at 14052147, | ||
// https://etherscan.io/address/0x49a33a28c4c7d9576ab28898f4c9ac7e52ea457a | ||
blockNumber: 14052140, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this specific block number? I imagine that we should actually fork without it to be on the latest state of the maker network
Otherwise, for now, you can take the block number where MCD_CLIP_WSTETH_A
didn't exist yet (ie 13426393 - 1
) and try to execute the spell which introduced it, then check if MCD_CLIP_WSTETH_A
exists in the chainlog
contract (which should at this point)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well, there's no reason for a specific block number:
- in order to test that e.g. the MCD_CLIP_WSTETH_A , i would also have to checkout different commit there
- because currently there is no collateral being introduced by the latest version of the spell.
also why i claimed in the verbal discussion that this runs without failure and not that it works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there's no reason for a specific block number
i would also have to checkout different commit there
Well, I still think that it makes sense to fork on a specific block number and maybe (as you suggest above) run a spell on a specific commit, in order to validate that contract that was not available is available after the execution
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the takeaway here is the additional test setup that might need to be created
One has to specify `ALCHEMY_URL` variable in the `.env` file that points the hardhat to the fork url. | ||
The `.env` file is to be located next to the `docker-compose.yml` file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One has to specify `ALCHEMY_URL` variable in the `.env` file that points the hardhat to the fork url. | |
The `.env` file is to be located next to the `docker-compose.yml` file. | |
In order to run the project, `collateral-onboarding/.env` file needs to be created with appropriate variables described below: | |
- `ALCHEMY_URL`: (required) [alchemy](https://www.alchemy.com) endpoint url (can be found in: apps table -> app -> view key) |
This narrows down to adding/removing the docker-compose directive `platform: linux/amd64`. If one desires to run the docker container separately then the | ||
flag has to be provided along with the rest of the `docker build` command: `--platform linux/amd64` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To which service it needs to be added? Can it be done without editing via a flag or env var? Eg will this work?
DOCKER_DEFAULT_PLATFORM=linux/amd64 docker-compose up --build --force-recreate
make | ||
dapp create DssSpell |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The python script contains calls to the etherscan which would fail since we run it on the fork instead
// Few blocks before WSTETH-A is taken at 14052147, | ||
// https://etherscan.io/address/0x49a33a28c4c7d9576ab28898f4c9ac7e52ea457a | ||
blockNumber: 14052140, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there's no reason for a specific block number
i would also have to checkout different commit there
Well, I still think that it makes sense to fork on a specific block number and maybe (as you suggest above) run a spell on a specific commit, in order to validate that contract that was not available is available after the execution
// Few blocks before WSTETH-A is taken at 14052147, | ||
// https://etherscan.io/address/0x49a33a28c4c7d9576ab28898f4c9ac7e52ea457a | ||
blockNumber: 14052140, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the takeaway here is the additional test setup that might need to be created
RUN curl -L https://dapp.tools/install | sh | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would this also run without errors?
RUN curl -L https://dapp.tools/install | sh | |
RUN curl -L https://dapp.tools/install | sh | |
RUN seth --version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
=> ERROR [tool-installs 6/6] RUN seth --version 0.4s
------
> [tool-installs 6/6] RUN seth --version:
#12 0.215 /bin/sh: 1: seth: not found
------
executor failed running [/bin/sh -c seth --version]: exit code: 127
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! From this I assume that dapp
tools did not correctly install despite finishing without error code. Correct me if I am missing something here
This issue is closed via adding a complete instruction in #506 unified-auctions-ui/core/README.md Lines 49 to 83 in cbf5727
|
References https://github.com/sidestream-tech/auction-ui/issues/430