Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ci(frontend): workflow to auto-deploy frontend in staging [GIX-3078] #2700

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
62 changes: 62 additions & 0 deletions .github/workflows/frontend-deploy-staging.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,62 @@
name: Deploy Frontend to Staging

on:
push:
branches:
- main
workflow_dispatch:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For workflow dispatch it would be nice to be able to choose the target network, so that this can also be used to deploy to the mainnet test canisters test_fe_1..4 But this can be done in another PR.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good one! Then we should rename the workflow too, better


jobs:
deploy-staging:
runs-on: ubuntu-latest

env:
VITE_ETHERSCAN_API_KEY: ${{ secrets.VITE_ETHERSCAN_API_KEY }}
VITE_INFURA_API_KEY: ${{ secrets.VITE_INFURA_API_KEY }}
VITE_ALCHEMY_API_KEY: ${{ secrets.VITE_ALCHEMY_API_KEY }}
VITE_WALLET_CONNECT_PROJECT_ID: ${{ secrets.VITE_WALLET_CONNECT_PROJECT_ID }}
VITE_OISY_URL: ${{ secrets.VITE_OISY_URL }}
VITE_AIRDROP: ${{ secrets.VITE_AIRDROP }}
VITE_AIRDROP_COMPLETED: ${{ secrets.VITE_AIRDROP_COMPLETED }}
VITE_COINGECKO_API_URL: ${{ secrets.VITE_COINGECKO_API_URL }}
VITE_COINGECKO_API_KEY: ${{ secrets.VITE_COINGECKO_API_KEY }}
VITE_JUNO_SATELLITE_ID: ${{ secrets.VITE_JUNO_SATELLITE_ID }}
VITE_JUNO_ORBITER_ID: ${{ secrets.VITE_JUNO_ORBITER_ID }}
VITE_POUH_ENABLED: ${{ secrets.VITE_POUH_ENABLED }}
VITE_AUTH_ALTERNATIVE_ORIGINS: ${{ secrets.VITE_AUTH_ALTERNATIVE_ORIGINS }}
VITE_AUTH_DERIVATION_ORIGIN: ${{ secrets.VITE_AUTH_DERIVATION_ORIGIN }}
VITE_NETWORK_BITCOIN_ENABLED: ${{ secrets.VITE_NETWORK_BITCOIN_ENABLED }}

steps:

- name: Fail if branch is not main
if: ${{ github.ref != 'refs/heads/main' }}
run: |
echo "This workflow can only be manually triggered with workflow_dispatch on the main branch"
exit 1
- name: Checkout
uses: actions/checkout@v4

- name: Prepare
uses: ./.github/actions/prepare

- name: Set up DFX
uses: dfinity/setup-dfx@main

- name: Install key
env:
DFX_DEPLOY_STAGING_KEY: ${{ secrets.DFX_DEPLOY_STAGING_KEY }}
run: |
key_pem=$(mktemp)
printenv "DFX_DEPLOY_STAGING_KEY" > "$key_pem"
dfx identity import --disable-encryption --force default "$key_pem"
Comment on lines +51 to +53
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
key_pem=$(mktemp)
printenv "DFX_DEPLOY_STAGING_KEY" > "$key_pem"
dfx identity import --disable-encryption --force default "$key_pem"
dfx identity import --storage-mode=plaintext --force default <(printenv DFX_DEPLOY_STAGING_KEY)
  • --disable-encryption has been deprecated and replaced with --storage-mode=plaintext
  • If you like (not obligatory) you can use a herefile as shown. Normally when dealing with key material one avoids letting it touch disk, but in this case the key material is landing in plaintext on disk anyway so it's a moot point.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that Internet Identity still uses --disable-encryption. We should do a scan of all our repositories and update them all. I'll add a Jira ticket to do that.

rm "$key_pem"
- name: Pre-build
run: npm run build

- name: Deploy to Staging
env:
ENV: staging
run: dfx deploy frontend --network staging
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we probably want to deploy the backend as well, however we can do that in another PR. That could be in this or another workflow. Here is an example of a workflow that deploys another project with 2 canisters to a test environment. It has a checklist for which canisters to deploy:

  workflow_dispatch:
    inputs:
      mode:
        type: choice
        description: "The dfx canister install mode.  See `dfx canister install --help` for details."
        options:
          - upgrade
          - reinstall
          - install
          - auto
      canisters:
        type: choice
        description: Which canisters to install
        options:
          - all
          - nns-dapp
          - sns_aggregator

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, I would first test if this one is all ok (deploying frontend takes less time, so less testing time). And in the next PR we add it