CI/CD for deployments and admin actions

[Ramarti]

After #10 , in order to have a better dev ex among the team, we could create a CD step for merges to main. I'd recommend basing them in the work I did in Forta (pioneered by Santiago Palladino)..

We need to decide if rewriting it to use Foundry instead of Hardhat is really worth the time.

This will create an auditable upgrade/config process, initially for internal dev ex, later for multisig ops.

In short:

• Have config files/ deploy scripts that clearly define the new versions of the contracts and params
• Make sure the IVersioned numbers in revelant contracts are increased
• Make sure we deploy tested AND verified sources
• Use OZ Defender to securely batch config txs and upgrades into a single tx to minimize downtime.

[leeren]

Starting a draft for a potential initial set of pipelines around this - here are some open-ended thoughts / questions to

• Given that the smart contract repo will be OSS, how will we want community contributions to mold into our CI/CD process? Clearly, we will want to automate local foundry / hardhat tests when users push out new issues or PRs, but down the road we'll also want to have integration tests for preventing breaking anything on the app-level. I think the simplest strategy initially is to package ABIs as part of our IaC repo, and leverage GH to only merge on successful integration tests passing on simulations in our dev / testing environment. Just like with traditional infra, we should focus on how we can promote artifacts, and treat sets of contract deployments and their ABIs as artifacts, with each environment mapped to a different blockchain network.

• We will need to deal with release cadence between APIs and smart contracts. Although we'll build out the API layer (which should be representative of our app layer) to be backwards-compatible with all smart contract releases, new API features might depend on new ABIs. Thus, the API layer should likely have per-version ABI dependencies.

• It does seem as though we will need to adapt entirely different CI/CD processes for new contracts (e.g. the main SP contract bumping from v0 to v1) vs. upgrades. For upgrades, what would you say the main benefits of using OZ Defender would be? Better tooling around 1967 upgrades, and a more secure approval system? The drawback is I can foresee this making it harder for us to create a more unifying SP-specific CI/CD workflow. But maybe using their API is worth it.

[LeoHChen]

some of my thinking,

• the initial goal for CI is to have a test pipeline setup for each PR.
• integration test is needed for each release, smart contract won't be auto deployed anyway
• low priority on upgrade in CI/CD as it won't be frequent

[Ramarti]

Given that the smart contract repo will be OSS, how will we want community contributions to mold into our CI/CD process? Clearly, we will want to automate local foundry / hardhat tests when users push out new issues or PRs, but down the road we'll also want to have integration tests for preventing breaking anything on the app-level. I think the simplest strategy initially is to package ABIs as part of our IaC repo, and leverage GH to only merge on successful integration tests passing on simulations in our dev / testing environment. Just like with traditional infra, we should focus on how we can promote artifacts, and treat sets of contract deployments and their ABIs as artifacts, with each environment mapped to a different blockchain network.

We do need integration tests, but we also better take into account the protocol what is going to be protocol and what community apps before tightly integrating both. Does it make sense to have an independent repo for the integration tests?

In any case, I think the flow could be

1. Community proposal and governance approval (pre launch, not needed)
2. We deploy to testnets through CI/CD, apps should already support new ABI compatibility and test the transition
3. We set a date for mainnet deployment to give time to the community to fix stuff
4. Submit governance proposal through CI/CD (initially multisig, later governor contract or whatever)
5. Smoke tests

This should not be that frequent after launch, but it's critical to do it in an auditable and public way, which could be through CI/CD. Having this automation also reduces dependency on 1 dev running scripts on his laptop

It does seem as though we will need to adapt entirely different CI/CD processes for new contracts (e.g. the main SP contract bumping from v0 to v1) vs. upgrades. For upgrades, what would you say the main benefits of using OZ Defender would be? Better tooling around 1967 upgrades, and a more secure approval system? The drawback is I can foresee this making it harder for us to create a more unifying SP-specific CI/CD workflow. But maybe using their API is worth it.

Upgrades == contract bumping from v0 to v1
Benefits:

• Easier devex to bundle and propose Safe txs through OZ Defender Admin that Safe SDK
• The flow I proposed generates an auditable trail of artifacts in GH
  Extra benefits of Defender
• We could setup alerts on contracts (via Forta or custom simple event listeners) that can call our webhooks, trigger the first signature of a system pause, interact with Pagerduty...
• Autotasks and relayers could really help with our meta tx or other "backend" interaction with contracts

I would argue the monitoring might be higher priority than the CI/CD?

[Ramarti]

For ABI availability, we could rely on Etherscan, or better add another CI/CD that verifies in Sourcify, which is more of a public good, IIRC over IPFS.