Collateral onboarding docker container.

[KirillDogadin-std]

References https://github.com/sidestream-tech/auction-ui/issues/430

[valiafetisov]

This make all only builds them, but doesn't execute
What dapp create DssSpell actually do? Can 1+ particular spell be executed instead?

[KirillDogadin-std]

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)

[valiafetisov]

The python script contains calls to the etherscan which would fail since we run it on the fork instead

[valiafetisov]

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)

[KirillDogadin-std]

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.

[valiafetisov]

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

[valiafetisov]

So the takeaway here is the additional test setup that might need to be created

[valiafetisov]

Suggested change

	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)

[valiafetisov]

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

[valiafetisov]

The python script contains calls to the etherscan which would fail since we run it on the fork instead

[valiafetisov]

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

[valiafetisov]

So the takeaway here is the additional test setup that might need to be created

[valiafetisov]

Would this also run without errors?

Suggested change

	RUN curl -L https://dapp.tools/install | sh
	RUN curl -L https://dapp.tools/install | sh
	RUN seth --version

[KirillDogadin-std]

 => 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

[valiafetisov]

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

[valiafetisov]

This issue is closed via adding a complete instruction in #506

unified-auctions-ui/core/README.md

Lines 49 to 83 in cbf5727

	### Onboarding not yet deployed collateral
	When a completely new collateral type support is being prepared, we need to ensure that it will work even before the Maker Protocol is changed via a [`spell`](https://docs.makerdao.com/smart-contract-modules/governance-module/spell-detailed-documentation). Usually a new spell is prepared in the [spells-mainnet](https://github.com/makerdao/spells-mainnet/pulls) repository. When it is there we need to fork the repository, compile the spell and deploy it into the hardhat fork. Currently the setup is as follows:
	1. `rsync` or clone the repo to the desired x86 machine (tested with Docker 19.03.12 on Ubuntu 20.04)
	2. `cd` into the `core/simulations/docker` and run `docker-compose up` to start the hardhat fork in one container and another container with installed [`dapp-tools`](https://github.com/dapphub/dapptools)
	3. Shell into the `spells` container
	- List avialble containers `docker container ls` (copy `CONTAINER ID` of the `docker_spells`)
	- Shell into the container `docker exec -it 277a8d793341 sh`
	4. Fix future `Invalid argument` `nix` error via `echo 'filter-syscalls = false' >> /etc/nix/nix.conf`
	5. Open `nix` shell with useful tools `nix-shell -p cacert cachix curl git jq nix gnumake nano`
	6. Update `dapp --version` to the supported version (currently 0.35.0)
	- Install `duppgrade` via `curl https://rari-capital.github.io/duppgrade/install | bash`
	- Execute `duppgrade` and wait
	7. Clone branch containing the spell
	- Clone the repo, eg `git clone https://github.com/makerdao/spells-mainnet spells && cd spells`
	- Checkout correct branch `git checkout CES-795`
	8. Fetch all libraries (that are linked via git submodules) using `dapp update`
	9. Create keystore (that will be used by dapp-tools)
	- Set hardhat private key into the file `echo 'ac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80' > ../private-key`
	- Set password `echo '' > ../key-password`
	- Import key to create a keystore folder `(printf "\n\n" && cat) | geth account import --datadir /root ../private-key`
	- Press enter to finish the process
	10. Prepare env vars
	- `export ETH_KEYSTORE="/root/keystore"`
	- `export ETH_PASSWORD="/root/key-password"`
	- `export ETH_RPC_URL=http://core:8545`
	- `export ETH_FROM="0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266"` - the address of the key from above
	- `export ETH_GAS=3000000` - might need to be adjusted based on the `make estimate` output
	- `export ETH_GAS_PRICE=1000000000000`
	11. Compile the spell via `make`
	12. Deploy the spell via `dapp create DssSpell`
	13. Copy the bitecode of the spell into the `core/bytecode/compiledSpells.json` file, which will automatically update the `Onboard new collateral` simulation
	14. Run `Onboard new collateral` locally to deploy compiled bytecode and execute the spell, create vault, liquidate vault to create auction
	15. Run keeper and frontend against the simulation to validate that it worked