You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Docker image for linux/amd64 with cartesi deploy build --platform linux/amd64
This command and its utility are currently not referenced in the CLI Commands Page. The only time a dev comes across it is when using the self-hosted deployment method using Fly. A suggested solution is to state its utility in the CLI Commands Reference pages clearly
Pushing the amd64 architecture to Fly.io is mandatory when using the Apple silicon Mac. But when you initially build and run cartesi deploy --hosting self-hosted --webapp https://sunodo.io/deploy, the default is the arm6 architecture. This later leads to errors when the user tries to push arm64 to fly.io.
When does the user run the cartesi deploy build --platinum linux/amd64? This is ambiguous in the docs.
How does the user inspect the docker image and architecture? Perhaps include docker inspect image <image-id> in deployment instructions
Troubleshooting tips for when they try pushing the wrong architecture. The typical approach that works is to delete all projects and create new ones with the amd64 architecture, but that's too tedious. Are any quick fixes available?
Fly.io secrets
The current docs recommend setting secrets using the terminal, which can be tricky and deals with copying and pasting stuff in the terminal. Multiple devs reported different experiences using backticks, double quotes, and single quotes.
A suggested solution will be to add the option of setting secrets interactively on Fly.io on the project dashboard
Production environments
In production environments, how does the user access important APIs like GraphQL, Explorer, and Inspect from their front end? The documentation is now ambiguous about this.
Inputs status
When a user runs into a situation where inputs that were successfully processed on their local device are reporting the UNPROCESSED status after deploying the node, what may be some possible causes and fixes?
The text was updated successfully, but these errors were encountered:
Docker image for
linux/amd64
withcartesi deploy build --platform linux/amd64
This command and its utility are currently not referenced in the CLI Commands Page. The only time a dev comes across it is when using the self-hosted deployment method using Fly. A suggested solution is to state its utility in the CLI Commands Reference pages clearly
Pushing the amd64 architecture to Fly.io is mandatory when using the Apple silicon Mac. But when you initially build and run
cartesi deploy --hosting self-hosted --webapp https://sunodo.io/deploy
, the default is thearm6
architecture. This later leads to errors when the user tries to pusharm64
to fly.io.cartesi deploy build --platinum linux/amd64
? This is ambiguous in the docs.docker inspect image <image-id>
in deployment instructionsFly.io secrets
The current docs recommend setting secrets using the terminal, which can be tricky and deals with copying and pasting stuff in the terminal. Multiple devs reported different experiences using backticks, double quotes, and single quotes.
Production environments
In production environments, how does the user access important APIs like GraphQL, Explorer, and Inspect from their front end? The documentation is now ambiguous about this.
Inputs status
When a user runs into a situation where inputs that were successfully processed on their local device are reporting the
UNPROCESSED
status after deploying the node, what may be some possible causes and fixes?The text was updated successfully, but these errors were encountered: