Fix race condition when running ./bin/cli.sh
#728
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This one was hard to catch, and probably the cause of many
venv
-related problems.In essence,
./bin/cli.sh
first makes sure that the cluster is up and running (docker compose up -d --no-recreate
), and thenexec
s into one of the CLI containers.In a fresh environment, the call to
docker compose up -d --no-recreate
will start the containers and initialise the python virtual environment (i.e. will call./bin/create_venv.sh
). The latter takes a while to finish, and if we exec into the CLI before it finishes (which callssource ./bin/workon.sh
), we break the installation.This can be reproduced by (literally):
The quick start tests circunvent this issue miraculously:
docker compose up
, we do it on thenginx
service (that does not start thecpp
andpython
services).cpp
or thepython
services, wedocker compose run
notdocker compose exec
(as the services had not been started before)../bin/inv_wrapper.sh
the./venv
directory is initialised from scratch correctly.This issue was brought up thanks to #726.