Update docs with steps on running migrations via Github Actions

MIGRATIONS.md

@@ -49,7 +49,28 @@ yarn hardhat migrate --network goerli --deployment usdc --prepare --simulate --i
 
 ## Running a Migration in GitHub
 
-The preferred way to run a migration is in GitHub, via manual workflow dispatch. The goal of this approach is that it's clear to everyone the exact code that ran, which affords less opportunity for "I'm looking at \<CODE X\>, but what was deployed was actually \<CODE Y\>." Look at "Prepare Migration" and "Enact Migration" dispatches in GitHub Actions in this repo (or any fork).
+The preferred way to run a migration is in GitHub Actions, via manual workflow dispatch. The goal of this approach is that to make it clear to everyone the exact code that ran, which affords less opportunity for "I'm looking at \<CODE X\>, but what was deployed was actually \<CODE Y\>." To get started, navigate to the [Github Actions tab](https://github.com/compound-finance/comet/actions). Note that only developers with certain permissions can run actions in the Comet repo, so you'll most likely have to run actions as part of your own fork of the repo.
+
+### Steps
+
+These are steps for enacting a migration. The steps for preparing a migration are similar (just switch out `Enact Migration` for `Prepare Migration`).
+
+ 1. Click on `Enact Migration` on the left-hand side of the Github Actions tab.
+ 2. Click on `Run Workflow`, which should bring up a dropdown with some fields to fill out:
+    - a. Select the branch that you will run your workflow from. Make sure that your migration exists on that branch.
+    - b. Select the network you plan to run the migration for from the `Network` dropdown.
+    - c. Fill in the `Deployment` (e.g. `usdc`, `weth`) that your migration script is targetting.
+    - d. Fill in the `Migration Name`, which is the string specified at the [top of your migration](https://github.com/compound-finance/comet/blob/main/deployments/mainnet/usdc/migrations/1659582050_raise_supply_caps_and_seed_reserves.ts#L4).
+    - e. (Optional) Fill in the `Run ID for Artifact` with the run id of your `prepare` job. If your migration does not have a `prepare` step, leave this field blank.
+    - f. (Optional) There is an optional field for providing a private key for signing transactions, but this is discouraged because you can run the workflow without exposing your private key by using WalletConnect.
+3. Start the migration by clicking the green `Run Workflow` button at the bottom of the dropdown.
+4. Click on the newly spun-up Github action once it appears in the list of workflow runs.
+5. Click on `Enact Migration`, which should appear as a pending job.
+6. If you did not input your private key when starting the action, the next steps will ask you to connect a wallet to the job using WalletConnect QR codes via [Seacrest](https://github.com/hayesgm/seacrest). You'll likely need a mobile wallet like Metamask to scan the QR codes.
+    - a. The first QR code to pop up should be under a task called `Seacrest`. In your mobile wallet, make sure you are connected to the network you specified in section 2b. Scan the QR code and accept the WalletConnect connection in your mobile wallet. Scanning the QR code can take some time since the QR code can be difficult to recognize, so try scanning with different angles.
+    - b. If your migration is targetting an L2 that is governed by another network (e.g. Ethereum mainnet governs Polygon, Arbitrum, Base, etc.), a second task called `Seacrest (governance network)` will run and also ask you to scan a QR code. Change the network in your mobile wallet to the governance network, which is usually going to be Ethereum mainnet. Then, scan the QR code.
+7. Once your address has been connected to the job (either via Seacrest or inputting your private key), the job will run your migration script. If you used Seacrest/WalletConnect, make sure to keep your mobile wallet open to accept any transactions it may ask you to sign (e.g. when making a proposal on-chain).
+8. After your migration script is run, the job should complete succesfully.
 
 ## Migration Artifacts
 

README.md

@@ -215,8 +215,6 @@ The same script that is used for testing can then be executed for real through t
 
 Once a proposal that's been made through a pull request has been executed by governance, the pull request should be merged into the `main` branch.
 The PR should include any necessary tests, which will remain in the repository.
-The migration script itself can be deleted in a separate commit, after the PR has been merged and recorded on the `main` branch, for good hygiene.
-It's important to remove migrations once they've been executed, to avoid exploding the cost of running scenarios beyond what's necessary for testing.
 
 For more information, seee [MIGRATIONS.md](./MIGRATIONS.md).