Proposal: Split the Deployment Workflow into Two Stages

[khanti42]

Context:

We currently have a single deployment workflow that handles building and publishing the StarkNet Snap, along with deploying get-starknet and wallet-ui. This workflow works fine for full deployments, but when we need to request allowlisting (which depends on the Snap’s shasum), we are required to wait before deploying the other components.

Problem:

The current workflow deploys everything at once, which creates the following issues:

1. Both wallet-ui and get-starknet target the new, not-yet-allowlisted Snap. This means any user trying to use the latest version will encounter failures.
2. Users attempting to upgrade to the latest version of the Snap will also experience failures, as the Snap hasn't been allowlisted yet.
3. We need to manually intervene to ensure that the Snap is allowlisted before deploying the wallet-ui and get-starknet, otherwise these components would target a Snap that isn't functional yet.

Proposed Solution:

We propose splitting the deployment process into two distinct workflows to improve the flexibility and streamline the allowlisting process:

1. Workflow 1: Build and Publish the Snap

   • Build the Snap with the correct version and environment settings.
   • Publish the Snap to npm.
   • Output the Snap’s shasum (snap.manifest.json) in the logs.
   • This will allow us to quickly request allowlisting using the published shasum without deploying get-starknet or wallet-ui.

2. Workflow 2: Publish Get-Starknet and Wallet-UI (after allowlisting)

   • After the Snap is allowlisted, trigger this workflow.
   • Deploy get-starknet and wallet-ui to AWS.
   • Ensure all components are correctly deployed after the Snap is verified and allowlisted.

Benefits:

• Reduced Downtime: By separating the workflows, the Snap can be published to npm before allowlisting. This allows us to wait for the allowlisting request to be merged in the Snap registry. Once the registry publishes the Snap, we can manually trigger the second workflow to deploy wallet-ui and get-starknet, resulting in much shorter downtime.
• Prevent User Failures: This separation ensures that wallet-ui and get-starknet only target the Snap after it has been allowlisted, preventing failures for users trying to use or upgrade to the latest version.
• Clear Separation of Responsibilities: Each workflow has a clear, isolated responsibility (Snap publishing vs. UI deployment), making it easier to manage and track progress.
• Manual Intervention to Trigger Workflow 2: Since allowlisting happens in another repository, automatic triggering of the second workflow isn’t possible. We will manually trigger the second workflow once the Snap is allowlisted and published.

Proposed Workflow Structure:

Workflow 1: Build and Publish Snap

• Trigger: Manual dispatch
• Steps:
  • Build the Snap.
  • Publish the Snap to npm.
  • Output the Snap’s shasum.

Workflow 2: Publish Get-Starknet and Wallet-UI

• Trigger: Manual dispatch
• Steps:
  • Build and deploy get-starknet.
  • Build and deploy wallet-ui.

Request for Feedback:

I’d like to gather feedback on:

• Whether this split workflow aligns with our current needs.
• Any additional considerations for triggering Workflow 2 once the Snap is allowlisted.
• Any concerns or suggestions about implementation or workflow management.

[khanti42]

@stanleyyconsensys wdyt ?