devnet in SDK

[tuler]

This PR adds to the SDK files from the @sunodo/devnet npm package that are necessary to boot an anvil with the Cartesi and test contracts.

Only two files are necessary:

1. anvil_state.json: state file used to load anvil with deployed contracts
2. localhost.json: information about deployed contracts (ABIs and addresses)

The localhost.json is actually used only to print-out information during anvil startup. I included a devnet shell script that was previously the entrypoint.sh file of the sunodo/devnet Docker image (which will be deprecated). The command to start the devnet from the sdk image is a little unhandy:

docker run -e ANVIL_IP_ADDR=0.0.0.0 -p 8545:8545  --entrypoint /usr/local/bin/devnet sunodo/sdk:devel anvil --load-state /usr/share/cartesi/anvil_state.json

Maybe we should provide an easier way to do that. I often use the devnet docker image as a very fast and convenient way to start an anvil with Cartesi by simply using the command:

docker run -e ANVIL_IP_ADDR=0.0.0.0 -p 8545:8545 sunodo/devnet:1.5.0

I published the @sunodo/devnet@1.5.0 manually to test this. Unfortunately the 1.5.0 had a bug in the publishing that it was not including the anvil_state.json file in the package. That bug is fixed in PR #479 . And there is a commit in this PR that must be deleted before merging.

[changeset-bot[bot]]

🦋 Changeset detected

Latest commit: 066d36ac437c4a7da73105fbd9c7273bea1d796c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

| Name | Type | | ----------- | ----- | | @sunodo/sdk | Minor |

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 26, 2024 5:25pm
www	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 26, 2024 5:25pm

[endersonmaia]

Maybe we should provide an easier way to do that.

We could ~craft a special~ edit our entrypoint.sh for the SDK with a devnet command.

Calling the sunodo/sdk container image like this would start a local anvil instance like before.

docker run -e ANVIL_IP_ADDR=0.0.0.0 -p 8545:8545 sunodo/sdk:1.5.0 devnet

[tuler]

We could ~craft a special~ edit our entrypoint.sh for the SDK with a devnet command.

docker run -e ANVIL_IP_ADDR=0.0.0.0 -p 8545:8545 sunodo/sdk:1.5.0 devnet

The current sdk entrypoint is only to do su-exec. As you said before I don't know if that is still necessary.

Regarding the devnet "entrypoint", does it need to be a docker entrypoint? Or is it enough to be a shell script in the /usr/local/bin that runs anvil with the required params? It's also often the case the users need to specify alternative arguments to anvil, like --block-time

[endersonmaia]

Didn´t test:

diff --git a/packages/sdk/entrypoint.sh b/packages/sdk/entrypoint.sh
index 7a13e6d..85d3970 100755
--- a/packages/sdk/entrypoint.sh
+++ b/packages/sdk/entrypoint.sh
@@ -1,5 +1,18 @@
 #!/bin/bash
+set -e

+# devnet entrypoint
+if [ "$1" = 'devnet' ]; then
+  if [ -z "$ANVIL_IP_ADDR" ]; then
+    echo "You should define ANVIL_IP_ADDR=0.0.0.0 and publish ports."
+    echo "usage: docker run -e ANVIL_IP_ADDR=0.0.0.0 -p 8545:8545 sunodo/sdk devner"
+    exit 1
+  fi
+  shift
+  exec anvil "$@"
+fi
+
+# global enptrypoint
 if [ -z "$GID" -o -z "$UID" -o -z "$USER" -o -z "$GROUP" ]; then
     exec "$@"
 else

[tuler]

diff --git a/packages/sdk/entrypoint.sh b/packages/sdk/entrypoint.sh

We don't need an entrypoint, right? Just a simple well crafted script.

[endersonmaia]

diff --git a/packages/sdk/entrypoint.sh b/packages/sdk/entrypoint.sh

We don't need an entrypoint, right? Just a simple well crafted script.

IDK, exec will ensure anvil will be the pid 1 inside the container and receive/pass the signals instead of depending on a shell.

[tuler]

exec will ensure anvil will be the pid 1 inside the container

Is that important?

[endersonmaia]

exec will ensure anvil will be the pid 1 inside the container

Is that important?

I think so.

And when we're not sure a program we want to run inside containers implements proper signaling handling, we can use docker run --init to do this work.

[tuler]

I think so.

How about an explicit alternative entrypoint to be used with --entrypoint?

docker run --entrypoint devnet (...)

[endersonmaia]

I think so.

How about an explicit alternative entrypoint to be used with --entrypoint?

docker run --entrypoint devnet (...)

There should only be a single default ENTRYPOINT, and you change based on the CMD, that you pass with docker run <image> CMD, that's the expected behavior of a container image.

Changing via --entrypoint if for when you want to bypass the default entrypoint.