Migrations from entrypoints

[endersonmaia]

This pull request includes several updates to the Docker Compose configurations for various services. The main changes involve updating the PostgreSQL image and simplifying the service definitions by merging migration steps into the main service entrypoints.

Updates to PostgreSQL image:

• apps/cli/src/compose/rollups/docker-compose-database.yaml: Updated the PostgreSQL image from postgres:16-alpine to postgres:16.
• apps/cli/src/compose/rollups/docker-compose-espresso.yaml: Updated the PostgreSQL image from postgres:16-alpine to postgres:16.
• apps/cli/src/compose/rollups/docker-compose-explorer.yaml: Updated the PostgreSQL image from postgres:16-alpine to postgres:16.
• apps/cli/src/compose/rollups/docker-compose-graphql.yaml: Updated the PostgreSQL image from postgres:16-alpine to postgres:16.

Simplification of service definitions:

• apps/cli/src/compose/rollups/docker-compose-graphql.yaml: Removed the graphql_database_migration service and integrated the migration commands into the graphql service entrypoint. Updated dependencies accordingly. [1] [2]
• apps/cli/src/compose/rollups/docker-compose-node.yaml: Removed the rollups-node-migration service and integrated the migration commands into the rollups-node service entrypoint. Updated dependencies accordingly. [1] [2]
• apps/cli/src/compose/rollups/docker-compose-paymaster.yaml: Renamed mock-verifying-paymaster service to paymaster for consistency.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 8967565

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[github-actions]

Coverage Report for ./apps/cli

Status	Category	Percentage	Covered / Total
🔵	Lines	27.43%	293 / 1068
🔵	Statements	27.41%	298 / 1087
🔵	Functions	27.27%	51 / 187
🔵	Branches	25.74%	121 / 470

File Coverage

No changed files found.

Generated in workflow #382 for commit 8967565 by the Vitest Coverage Report Action

[tuler]

For the reasons explained at https://www.docker.com/blog/docker-best-practices-choosing-between-run-cmd-and-entrypoint/ I highly prefer to use exec form only, and not use ENTRYPOINT to run database migrations through shell.
I don't think it's a correct usage of ENTRYPOINT, and I think it's fine to use a container to do database initialization.

Another strategy I see around is the software itself takes care of database initialization, which has the advantage of guaranteeing the correct migration is executed. But rollups-node and rollups-graphql are not doing that.

[endersonmaia]

For the reasons explained at https://www.docker.com/blog/docker-best-practices-choosing-between-run-cmd-and-entrypoint/ I highly prefer to use exec form only, and not use ENTRYPOINT to run database migrations through shell. I don't think it's a correct usage of ENTRYPOINT, and I think it's fine to use a container to do database initialization.

I agree with the reasons mentioned in the post, but mostly it's ok for single purpose containers, that's not our case. We have an SDK container that has a lot of auxiliary tools and services inside, the container itself is used to bundle everything and ensure compatibility with every tool for the cartesi environment.

What I'm trying to achieve with removing those one-shot containers that are used for migrations (and even createdb) is reduce the noise exposed to the cartesi/cli user when running cartesi start and also the number of containers to debug when necessary via docker compose directly.

If you agree, I think we could enhance the cartesi/sdk container image with en entrypoint that could be used from cartesi/cli and even calling docker run cartesi/sdk directly if necessary.

Another strategy I see around is the software itself takes care of database initialization, which has the advantage of guaranteeing the correct migration is executed. But rollups-node and rollups-graphql are not doing that.

For that, I suggest talking to those project's teams and issue a feature request if we think it's

---

I'm closing this and will get back to it if we decide to have an entrypoint defined at cartesi/sdk and reuse if from the cli.

[tuler]

reduce the noise exposed to the cartesi/cli user when running cartesi start

Noise of the pull or the start itself?
Start only monitors services, not the one-shot.
And pull has to pull anyway once, and I believe layers are only fetched once.

[endersonmaia]

Noise of the pull or the start itself?

Yes.

Start only monitors services, not the one-shot.

That's fine.

And pull has to pull anyway once, and I believe layers are only fetched once.

For example:

✗ cartesi-dev rollups start --services graphql,espresso
WARNING: default block is set to 'latest', production configuration will likely use 'finalized'
[+] Pulling 12/12
 ✔ espresso_reader_migration Skipped - Image is already being pulled by anvil                                                                                                                                                                                                                                    0.0s
 ✔ graphql_database_migration Skipped - Image is already being pulled by anvil                                                                                                                                                                                                                                   0.0s
 ✔ espresso Skipped - Image is already being pulled by anvil                                                                                                                                                                                                                                                     0.0s
 ✔ rollups-node Skipped - Image is already being pulled by anvil                                                                                                                                                                                                                                                 0.0s
 ✔ espresso_database_creator Skipped - Image is already being pulled by graphql_database_creator                                                                                                                                                                                                                 0.0s
 ✔ graphql Skipped - Image is already being pulled by anvil                                                                                                                                                                                                                                                      0.0s
 ✔ database Skipped - Image is already being pulled by graphql_database_creator                                                                                                                                                                                                                                  0.0s
 ✔ rollups-node-migration Skipped - Image is already being pulled by anvil                                                                                                                                                                                                                                       0.0s
 ✔ espresso_reader Skipped - Image is already being pulled by anvil                                                                                                                                                                                                                                              0.0s
 ✔ proxy Pulled
....