Default CI/CD

[acedward]

Templates do not have a default CI/CD mechanism.
The overall steps to deploy a game are:

1. Stop Paima Engine & Batcher
2. Store the current block height and take a snapshot of the database.
3. Build Frontend and Backend.
4. Apply Custom Migrations
5. Upload Frontend, Backend, Paima-Engine, .env, config, extensions. ABI.json(s)
6. Start Backend & Batcher

---

Some difficulties & proposals.

1 & 2

• This could be simplified if we had some command to dynamically stop the backend and batcher at some specific block height, or an API call to end, returning the block height e.g., POST /api/stop-engine/{block_height} returns {"status": "ok": "chain_block_height": 5000, "emulated_block_height": 100 } (This would have to be a secure endpoint)
• Another alternative is sending a concise command with an alias-name to stop the build. (This will help for the migrations) e.g.,&stop|alias_stopped_july_8
• We can move the snapshot to the cloud provider and give the instructions for a specific provider, advanced deployments can move this particular provider's API, and ideally call the snapshot something related to the block height. e.g., snapshot-5000
  e.g.,

# Snapshot a Droplet
curl -X POST \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $DIGITALOCEAN_TOKEN" \
  -d '{"type":"snapshot","name":"Nifty New Snapshot"}' \
  "https://api.digitalocean.com/v2/droplets/3164450/actions"

4

Currently, the Automatic Migration system uses relative block height to apply a migration e.g., 100.SQL gets applied at block height start+100, the issue with this is:

• Different environments have different block heights
• Not all patches are applied to all environments
• Hard to predict where will the build stop

We can allow the config.network.yml to set this up for different environments

migration:
  file_1.sql: 
    - 1000 
    - relative
  file_2.sql:
    - 3000
    - absolute
  file_2.sql:
    - 1
    - alias
    - alias_stopped_july_8
  file_3.sql: 5000

1 & 3 & 5

• A docker image with: /packaged, .env, config, extensions, ABI.json(s), paima-engine to solve the complex exact dependency requirements.
• And a second docker image with a static image server and frontend

The main problem here is that paima-engine is a large binary file.
If Paima would publish public paima-engine as a docker image over alpine, we could build lightweight images over this base image.

Putting it all together

1. The developer names this deployment alias_stopped_july_8 and uses this value in config for migrations.
2. The CI CD builds and pushes the frontend and backend image (based on paima-engine image)
3. The CI CD sends a concise command and waits for the server to stop.
4. The CI CD calls the Cloud service to stop snapshot the hard drive
5. The CI CD pulls and starts the Docker Images

TL;DR

• Official paima-engine / apline docker images
• Update migration system allow setup though config files
• Game Docker Files to pack backend / frontend
• github CI CD, read some file .paima-ci-cd with the stop alias, and do the steps above