This repository contains a tool that helps starting Katana sequencer on demand (mostly for CI purposes).
To work, the katana-ci
binary must be deployed on a server with docker installed.
To keep things simple and flexible for CI, the katana-ci
uses docker under the hood.
With an file
database for now, each user have an api-key
that allows the start
and stop
of a Katana instance.
When a user starts an instance, a new container is created and started.
The database trait ProxifierDb
is for now targetting Sqlite
, but may be reworked to support any backend supported by sqlx
rust crate.
To quickly spin up katana-ci
server, you can do the following:
- Install docker on your machine, for example:
snap install docker
. - Download the binary from the release (or build from source)
wget -q -O katana-ci https://github.com/ArkProjectNFTs/katana-ci/releases/download/v0.1.0/katana-ci_amd64 chmod +x katana-ci
- Pull the docker image of katana (or use your own):
docker pull arkproject/katana:0.3.1
- Setup environment file with initial users and docker image ID:
The
# .env export KATANA_CI_IMAGE=<ID_OF_IMAGE> export KATANA_CI_USERS_FILE=.users
.users
file contains a simple list of initial users with their name and API-KEY, for example:user1,mykey user2,1234
- Run the binary to be ready to spawn katana instances from your CI:
# Create the database file for SQLite. In the current version, if you # don't delete the file and restart the binary you will see an insertion error # of the users, that's normal, users are still in the DB and we don't check for existence. touch data.db # Source environment variables. source .env # Let's run. ./katana-ci
To setup your action in the GitHub CI, you can check the full example in .github/workflows/example.yml, and you also have a test in examples/e2e.rs with
all basic actions on a contract with starknet-rs
-> declare, deploy (which is an invoke with the UDC), call.
You can use the katana-ci-action to abstract the call to the katana-ci
server.
Basically, you call the action first to start the katana:
- name: Startup Katana CI instance
id: katanaci
uses: ArkProjectNFTs/katana-ci-action@v1
with:
api-url: ${{ secrets.KATANA_CI_URL }}
api-key: ${{ secrets.KATANA_CI_KEY }}
cmd: 'start'
You can then inject the URL of the spawned instance in your tests, in the example we use environment variable to pass it:
- name: Run cargo test
uses: actions-rs/cargo@v1
env:
STARKNET_RPC: ${{ steps.katanaci.outputs.katana-rpc }}
with:
command: run
args: --example e2e
And then you call it again to stop it:
- name: Terminate Katana CI instance
uses: ArkProjectNFTs/katana-ci-action@v1
with:
api-url: ${{ secrets.KATANA_CI_URL }}
api-key: ${{ secrets.KATANA_CI_KEY }}
cmd: 'stop'
name: ${{ steps.katanaci.outputs.katana-name }}
It can be a good refacto to use js
actions, in order to leverage the post
cleanup.
The idea is to have the least overhead possible to spawn and interact with a Katana instance. So no client is designed for now,
and you can use very common tools like curl
.
-
Start an instance
curl -H 'Authorization: Bearer mykey' https://<your_backend_url>/start # Returns a simple string with the name of the created instance. 4f2b3c60ae32
The start will return an instance
name
, that can then be used to target Katana for this specific instance. Thename
returned is always URL friendly. -
Use
starkli
to interact with the instance, for example:starkli block --full --rpc https://<your_backend_url>/<name>/katana
-
To check the logs, you can hit the endpoint
/logs
of your instance, by default it returns25
tail lines. You can useall
or any number you like using the query parametern
.curl -H 'Authorization: Bearer mykey' https://<your_backend_url>/<name>/logs curl -H 'Authorization: Bearer mykey' https://<your_backend_url>/<name>/logs?n=100
-
Then, you can stop the instance if it's no longer needed.
curl -H 'Authorization: Bearer mykey' https://<your_backend_url>/<name>/stop