OriginProtocol / OriginProtocol/origin-dollar
Contracts deploy automation by using a continuous integration pipeline
Nobody has claimed this yet.
- Dominant language
- Solidity
- Stars
- 152
- Forks
- 115
- Avg merge
- 3d 20h
- Merged PRs (30d)
- 17
Description
As part of deploying new contracts to Mainnet, we have an internal checklist (aka "OUSD Deploy / Launch plans) which includes a battery of manual tests and verifications performed by the engineer doing the deploy.
- Slither
- Echidna
- Smoke tests
- Manual tests by invoking hardhat tasks from the cli
This is a labor intensive and error prone process.
By implementing a "CI" (Continuous Integration) pipeline, we could significantly reduce the amount of manual work necessary for deploys:
Phase I: Development and automated testing
- Any commit on a branch and on master kicks off a series of tests using GitHub actions and runners. Including
- Slither (we already have that)
- Echidna. This is very CPU intensive (takes in the order of ~30min to run on my laptop). We could mitigate by using different strategies: parallelize the runs on multiple workers, only run for contract changes (vs DApp changes)
- Smoke tests. Run those against a forked hardhat node. Notes:
- We should expand those tests to also include the manual tests described in step 4 above.
- When running in fork mode, the deploy script should also automatically execute the associated governance proposal that performs the upgrade - so that the tests run against the new contracts.
Phase II: Deployment (manual)
- Once all the tests are green and the PR with the contract(s) change is merged to master, an engineer manually runs the deploy against Mainnet.
- This does not take up much time. Though we might want to look into ways of improving recovery in case of failures (see #945 )
Phase III: Governance proposal validation (automated testing)
- The deploy to Mainnet generates files (ABIs, hardhat deployment file) that must be committed to the repo via a PR. We can use this PR to run another round of validation to ensure the governance proposal works as expected on the newly deployed contracts
- At this point, the upgrade hasn't been activated on Mainnet yet since the governance proposal associated with the deploy is still going thru approval, timelock (2 days) and execution
- We could add a bit of logic so that when the tests run in fork mode, we check if there is any pending proposal (by querying the governor contract). If so, execute the proposal before running the tests.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the existing smoke tests in contracts/scripts/test/smokeTest.sh and the manual hardhat tasks under contracts/tasks, then inspect the repository's current GitHub Actions setup. Define the CI phases and forked-node behavior before implementation. Done means the listed contract checks run automatically with clear handling for contract-only changes, deployment artifacts, and governance proposals.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, solidity
- Domain
- blockchain, ci-cd, devops, testing-qa
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100