chore: two steps CI CD deployment

[khanti42]

Why This Change?

Goal

To safely test new snap versions in production (e.g. on MetaMask not MetaMask Flask) before forcing updates on end-users:

The new workflow would be

1. Deploy new Snap to NPM
2. Allowlist the new version
3. Test the new version with MetaMask locally
4. Deploy new wallet-ui and get-starknet

Solution

Split the workflow into two parts:

1. Publish NPM:

   • Build and publish starknet-snap.
   • Output version for allowlisting and validation.

2. Deploy UI and Get Starknet:

   • Build and deploy wallet-ui and get-starknet separately after snap validation.

Known Limitations

• get-starknet Wildcard Behavior:
  • Always targets the latest allowlisted snap (*).
  • Cached Webpack modules in dApps may not fetch the updated snap, potentially causing errors.
• Manual Steps:
  • This split workflow introduces a manual step between publishing the snap and deploying related components. However, this is necessary for controlled testing.

Benefits

• Controlled production testing for snaps.
• Prevents breaking changes for get-starknet users.
• Flexible foundation for future deployment improvements.

[stanleyyconsensys]

some ENV setup incorrect
and i would suggest keep this 2 new pipeline for production only

[stanleyyconsensys]

some remove of cache key, but not sure does it work, needed to test

[sonarcloud]

Quality Gate passed for 'consensys_starknet-snap-wallet-ui'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sonarcloud]

Quality Gate passed for 'consensys_starknet-snap-starknet-snap'

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud