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
Improving upon Bartek's initial implementation of #2812 we can use docker compose to spin up a new stand alone network instead of using the stellar quick start docker image.
The advantage of using docker compose is that we can simplify the integration test scaffolding. In the current implementation, we use the golang docker client to programmatically create a docker container from the quickstart image to run the standalone network. Instead, we can simply run the start script as a shell command to spawn the standalone network. For the tear down process we can run docker-compose down -v as a shell command.
Another big advantage of using the docker compose workflow is that we don't need to build a horizon binary from source and copy it over to the quickstart docker container.
We will need to modify the docker-compose workflow slightly in order to support the integration tests workflow.
In particular, we need to make sure that horizon ingest init-genesis-state is executed when horizon starts running the stand alone network. Otherwise, Horizon ingestion will not start until the first checkpoint ledger is created by stellar core which takes around 5 minutes.
We also will need to make the protocol version configurable in the docker compose workflow. At the moment, the protocol version for the stand alone network is hard coded in the docker-compose yaml file.
The text was updated successfully, but these errors were encountered:
Improving upon Bartek's initial implementation of #2812 we can use docker compose to spin up a new stand alone network instead of using the stellar quick start docker image.
The advantage of using docker compose is that we can simplify the integration test scaffolding. In the current implementation, we use the golang docker client to programmatically create a docker container from the quickstart image to run the standalone network. Instead, we can simply run the start script as a shell command to spawn the standalone network. For the tear down process we can run
docker-compose down -v
as a shell command.Another big advantage of using the docker compose workflow is that we don't need to build a horizon binary from source and copy it over to the quickstart docker container.
We will need to modify the docker-compose workflow slightly in order to support the integration tests workflow.
In particular, we need to make sure that
horizon ingest init-genesis-state
is executed when horizon starts running the stand alone network. Otherwise, Horizon ingestion will not start until the first checkpoint ledger is created by stellar core which takes around 5 minutes.We also will need to make the protocol version configurable in the docker compose workflow. At the moment, the protocol version for the stand alone network is hard coded in the docker-compose yaml file.
The text was updated successfully, but these errors were encountered: