OriginProtocol / OriginProtocol/origin-dollar

Contracts deploy automation by using a continuous integration pipeline

Open
#944 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

devops
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.

  1. Slither
  2. Echidna
  3. Smoke tests
  4. 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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.