[brunomenezes]

Summary

TBD.

ps: However as usual including a droppable wip commit at the base that besides some plumbing is squashing/cherry-picking #562 changes.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🟢	Lines	88.56% (🎯 0%)	13728 / 15501
🔵	Statements	88.56%	13728 / 15501
🔵	Functions	82.27%	348 / 423
🔵	Branches	0%	0 / 0

📁 File Coverage (20 files)

File	Lines	Statements	Functions	Branches	Uncovered Lines
apps/cli/src/base.ts	🔴 38.6%	🔴 38.6%	🟡 64.71%	🔴 0%	62, 70-74, 79, 101-174, 200...
apps/cli/src/builder/directory.ts	🟢 100%	🟢 100%	🟢 100%	🔴 0%	-
apps/cli/src/builder/docker.ts	🟢 87.12%	🟢 87.12%	🟡 66.67%	🔴 0%	77-79, 81, 114-116, 174-183
apps/cli/src/builder/empty.ts	🟢 100%	🟢 100%	🟢 100%	🔴 0%	-
apps/cli/src/builder/none.ts	🟢 100%	🟢 100%	🟢 100%	🔴 0%	-
apps/cli/src/builder/nvram.ts	🟢 97.14%	🟢 97.14%	🟢 100%	🔴 0%	38
apps/cli/src/builder/tar.ts	🟢 100%	🟢 100%	🟢 100%	🔴 0%	-
apps/cli/src/commands/foreclose.ts	🔴 49.09%	🔴 49.09%	🔴 50%	🔴 0%	69, 91-145
apps/cli/src/commands/logs.ts	🟡 66.67%	🟡 66.67%	🟡 66.67%	🔴 0%	13-24, 106-124
apps/cli/src/commands/refund.ts	🔴 38.2%	🔴 38.2%	🟡 66.67%	🔴 0%	55-109
apps/cli/src/commands/run.ts	🔴 17.47%	🔴 17.47%	🔴 8.33%	🔴 0%	69-88, 92-259, 263-270, 277...
apps/cli/src/commands/withdraw.ts	🔴 46.58%	🔴 46.58%	🟡 73.33%	🔴 0%	95-123, 277-278, 301-356, 3...
apps/cli/src/compose/anvil.ts	🟢 100%	🟢 100%	🟢 100%	🔴 0%	-
apps/cli/src/compose/builder.ts	🟢 99.79%	🟢 99.79%	🟢 100%	🔴 0%	228
apps/cli/src/compose/bundler.ts	🔴 4.82%	🔴 4.82%	🔴 0%	🔴 0%	8-40, 44-75, 79-92
apps/cli/src/compose/common.ts	🟢 100%	🟢 100%	🟢 100%	🔴 0%	-
apps/cli/src/compose/database.ts	🟢 100%	🟢 100%	🟢 100%	🔴 0%	-
apps/cli/src/compose/explorer.ts	🔴 6.67%	🔴 6.67%	🔴 0%	🔴 0%	10-38, 43-55, 59-72
apps/cli/src/compose/node.ts	🟢 100%	🟢 100%	🟢 100%	🔴 0%	-
apps/cli/src/compose/passkey.ts	🔴 8.33%	🔴 8.33%	🔴 0%	🔴 0%	9-18, 23-42, 46-59

[changeset-bot]

🦋 Changeset detected

Latest commit: 813d17d

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

This PR includes changesets to release 1 package

Name	Type
@cartesi/cli	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

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​cartesi/​wagmi-plugin@​1.0.0-alpha.7 ⏵ 1.0.0-alpha.9	+1		+1	+1

View full report

[brunomenezes]

Hey @endersonmaia could you have a look in the following commits, check if see any problems or improvements in the following commits
b474393, bfb4d91, 2902204. They touch the compose for secret copy and some fixes for escaping the $ when forward values to avoid corruption of these values when docker could mistakenly apply variable “interpolation”.

[endersonmaia]

I see you're using new containers for the sentry, but have you tried scaling them instead of new instances?

So, instead of creating a new instance sentry-1, sentry-2 that will show sentry-1-1 and sentry-2-1,

Use the docker compose scale sentry=2, then we leverage what compose already provides to scale services instead of wiring it from the outside.

---

On another end, we could leverage nitro that's already inside cartesi/rollups-runtime image., and use it to start new instances for sentries, using templates like /etc/nitro/cartesi-sling-node@

This way we wouldn't need to spin up a new container.

This would consume less resources BUT may be more complicated since there's already a Service abstraction that controls the containers.

---

The test I did with sentries works, with 2 sentries and sending a couple of inputs and I can see logs and stuff.

The suggestions above are just suggestion, nothing blocker.

[endersonmaia]

In see you used a bind mount to expose the secret content, that's what docker compose already does via its secrets:

Just like we already do with config:

Is there any reason why you didn't use the secrets:?

https://docs.docker.com/compose/how-tos/use-secrets/

[brunomenezes]

I see you're using new containers for the sentry, but have you tried scaling them instead of new instances?

So, instead of creating a new instance sentry-1, sentry-2 that will show sentry-1-1 and sentry-2-1,

Use the docker compose scale sentry=2, then we leverage what compose already provides to scale services instead of wiring it from the outside.

I did not think on using "scaling" for that. However, the sentries aren't identical replicas. Each one has its own signer (a devnet account or a key file), data dir and label, and a later type may run a different binary (ref-node as sentry and Diego's Lua named Crisium) that is why the config is designed with type. Compose has no per-replica environment, so scale can't give replica 2 a different key. Distinct services keep each sentry's config, logs and cleanup separate, the -1 suffix is compose's replica numbering and I can set container_name to drop but this suffix is everywhere. Instead of the fallback sentry index you can use the optional label so it would be sentry-green-1 like the screenshot below.

Sentries with label

Are you thinking on using replicas when running sentries on your environment? Same signer and configs? On this branch I am separating devnet accounts to avoid the lately wide spread problems with nonces. I also defined a pool of high accounts just for sentries, I reserved accounts from index 20 to 29 (that is more than enough I assume, for testing using devnet)

On another end, we could leverage nitro that's already inside cartesi/rollups-runtime image., and use it to start new instances for sentries, using templates like /etc/nitro/cartesi-sling-node@

This way we wouldn't need to spin up a new container.

This would consume less resources BUT may be more complicated since there's already a Service abstraction that controls the containers.

I think you are spot on in the "more complicated" and not as much of again to be honest. But being a bit more deep on my answer; the @ template would save the rescan on start, but nitro only passes $1 to run and has no per-service environment, so the app address, endpoint and key would still have to be written into the running node container through docker exec, and the same for stop/wipe/restart across a shell rebuild and for reading logs back. The keys would also sit in the node's container, readable by every node process (I know devnet, mostly of the time). The template itself would live in the image's skel/etc/nitro, written for the CLI's conventions, so the CLI would only work with runtime versions that ship it. The runtime image should stay a neutral bundle of binaries that any orchestrator can use, with the orchestration knowledge in the CLI. As I see it the suggestion creates that coupling for little gain, one cgroup per sentry, given the lifecycle work above. compose gives all of it as up/down of a named service, so I kept them as services.

[brunomenezes]

In see you used a bind mount to expose the secret content, that's what docker compose already does via its secrets:

Just like we already do with config:

Is there any reason why you didn't use the secrets:?

https://docs.docker.com/compose/how-tos/use-secrets/

There is a problem identified by the rollups-node team a couple of weeks/months ago. The compose file secrets: are plain bind mounts, and uid/gid/mode are ignored outside Swarm. On Docker Desktop that's invisible because ownership is remapped, but on Linux a 0600 key owned by the host user is unreadable to the node's uid 102, and cartesi/rollups-node#790 would reject a key the node doesn't own. So an init service copies each key into a volume as cartesi:cartesi 0400, which is also what cartesi/rollups-node#790 compose.yaml does. configs: is fine for the traefik file because it's world-readable, so ownership never mattered there.

node-startup.test.ts covers it. The node starts on 0600 key files owned by the test's user and must log the identity read from them, which a plain bind mount can't give on Linux CI, where that user isn't uid 102. I'll extend it to check the copies are cartesi:cartesi 0400 and the host files keep their owner and mode, so it also fails on macOS, where Docker Desktop remaps ownership, and guards the copy against regressions.