Improving deployment cases

[grod220]

The current state

• Web app
  • Deploys upon every pull request merge
• Extension
  • Sent to chrome for review when github release is made
  • Takes 1-4 days for chrome team to approve
  • Approved extension automatically publishes to chrome web store
• Penumbra Chain
  • Testnet
  • Deployed every ~2 weeks
  • No code freezes before deployment
  • Used by users externally
  • Preview
  • Deployed upon every PR merge
  • Meant to test the latest work for internal use

Impact

This leaves us in a bit of a weird place for a few reasons:

• The web app updates can (and regularly does) break compatibility with the latest extension in chrome web store. Creates troubleshooting issues in discord for testnet users.
• Every testnet deploys breaks the extension. Causes development time + review time for users to use again. Note: there is no code freeze on testnet deploys. In theory this would help, but we have specifically not required this to not slow protocol development. When mainnet launches, we should impose testnet code freezes to buy the web team time to get things working.

Possible solutions

• Web app. Deploy different versions (corresponding to branches):
  • Main - Public version. Deploys along with newly published extension (need to sync these manually)
  • Dev - Deploys upon every PR merge. Corresponds to Penumbra testnet chain.
    • Do we need a preview branch for testnet-preview chain?
• Extension
  • Find a way to deploy extension, get a review, and wait to publish. This will allow us to sync our public web app deployments.
• Chain
  • Do nothing for the time being. At mainnet, implement testnet code freezes.

[turbocrime]

chainParams provides testnet version to client, yeah? can we package.json depend on two buf registry package versions? corresponding to last tagged release / next tagged candidate, and condition on chain version reported by endpoint.

endpoint is on the viewprotocolservice - can we be confident in success querying this endpoint? connectrpc provides a convenient way to one-off a client with a single methodtype as of last release. maybe we should have an truncated view service definition for constructing a 'test client' for things like grabbing chain version and also testing a user-configured rpc endpoint

i don't think we can do anything about extension review process - we have to release early and extensions have to anticipate the possibility of encountering a few chain versions.

[hdevalence]

No, the testnet version is not included in the chain parameters. Also there have been breaking proto format changes that will wreck everything.

However, the important context is that this is the last set of breaking changes to the protos we intend to make before mainnet. So my inclination is that it may be simplest to just bite the bullet on breaking changes for a week where the frontend site doesn't work with the current testnet, then going forward we'll have an extension that will work with both testnet and testnet-preview (even if they have different chain logic).

After the current set of proto changes, the extension should continue to work with new testnets without re-releasing, because we will have stabilized the Penumbra client protocol. From that point on, the web story should be simpler, because it will only be about managing breaking changes between the frontend site and the extension (until such time as we can stabilize that interface, hopefully before mainnet).