microcks start returns as soon as the container is created, but the Microcks server inside takes a few seconds to actually come up. So if you immediately run microcks import or microcks test after starting, you get a connection refused error and have to either sleep or retry manually.
microcks start
microcks import myapi.yaml # connection refused
The Microcks Testcontainers module already handles this by polling GET /api/health before handing control back to the caller. Would be good to have the same in microcks start via a --wait flag, optionally with a --wait-timeout.
microcks start --wait
# blocks until /api/health returns 200
This also ties into the --dry-run work in #255, where the ephemeral container needs to be ready before importing and testing.
@lbroudoux @yada @Harsh4902 would a --wait flag work here, or would you prefer readiness wait to be always-on?
microcks startreturns as soon as the container is created, but the Microcks server inside takes a few seconds to actually come up. So if you immediately runmicrocks importormicrocks testafter starting, you get a connection refused error and have to either sleep or retry manually.microcks start microcks import myapi.yaml # connection refusedThe Microcks Testcontainers module already handles this by polling
GET /api/healthbefore handing control back to the caller. Would be good to have the same inmicrocks startvia a--waitflag, optionally with a--wait-timeout.microcks start --wait # blocks until /api/health returns 200This also ties into the
--dry-runwork in #255, where the ephemeral container needs to be ready before importing and testing.@lbroudoux @yada @Harsh4902 would a
--waitflag work here, or would you prefer readiness wait to be always-on?