-
Notifications
You must be signed in to change notification settings - Fork 11
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
Cartesi Rollups v2 #116
Cartesi Rollups v2 #116
Conversation
🦋 Changeset detectedLatest commit: 24ad87e The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
d8e88da
to
1b2868f
Compare
1b2868f
to
5c9f7c3
Compare
bd0df04
to
f54fe46
Compare
b4e999f
to
78b5056
Compare
78b5056
to
d2c37a4
Compare
a82afdd
to
a7e55c5
Compare
8d2a41d
to
f3b6918
Compare
|
|
|
|
44df851
to
1297ea6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this PR is mine, I can't request changes.
39558cf
to
d496299
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The send
behavior is still weird.
Even if I define the --dapp
argument, it will override with the address of the dapp from the directory I'm calling the command from.
--dapp
should take precedence
I think this is commander bug. Opened an issue at tj/commander.js#2335 |
Problem solved. ps: there are two ways of structuring commands and subcommands in commander.
I was using (1), but switched to (2). |
Need to check why the graphql container is continuously printing:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... send --dapp=
is working as expected
@tuler I think we're good to go |
Regarding the start + start issue, I was thinking of an elegant way to handle it without checking first if it's running. What happens now is that docker compose up, when executed again, "reapplies" the services, which is usually harmless. But the one-shot containers get reexecutes, and the one which creates the graphql database fails because the database already exists. The solutions to create only if exists are all ugly and not elegant. |
except that we need a rollups-node v2 release 🫠 |
b295744
to
48ddef2
Compare
Applied the idea of #151 but without the extends, just using an env var for the SDK image name. |
caf7a2f
to
c2a395d
Compare
6bdb4c1
to
b999336
Compare
b999336
to
24ad87e
Compare
This is support for Rollups V2.
The
run
command has been deprecated and replaced by two separate steps:rollups start
androllups deploy
.The following are the new commands:
ps:
deploy
(notrollups deploy
) will probably be deprecated. Or we may use acartesi.toml
property to redirect commands from<root>
to eitherrollups
or (upcoming)coprocessor
.The following flow works for me. Please help test.