Currently, even if we don't mount the source code for Faasm, we still mount the clients code (i.e. clients/cpp and clients/python) from ./clients/cpp and ./clients/python). I link the offending lines.
This has a domino effect:
- Even if not mounting the source code, we need to clone
faasm with all the submodules. Theoretically, we could get away with just wget-ing the docker-compose.yml file, but that's not necessary neither. I think one shallow clone from the tag without submodule is enough (and can also be shared with k8s deployments).
- Even if not mounting the source code, we need to wait for the
venvs in client/{cpp,python}/venv/faasm_venv.BUILT.
- Even if we bump the
faasmctl version in clients/cpp (and bump the container tag to have faasmctl inside the contianer), we also need to bump the main faasm tag.
Currently, even if we don't mount the source code for Faasm, we still mount the clients code (i.e. clients/cpp and clients/python) from
./clients/cppand./clients/python). I link the offending lines.This has a domino effect:
faasmwith all the submodules. Theoretically, we could get away with justwget-ing thedocker-compose.ymlfile, but that's not necessary neither. I think one shallow clone from the tag without submodule is enough (and can also be shared withk8sdeployments).venvs inclient/{cpp,python}/venv/faasm_venv.BUILT.faasmctlversion inclients/cpp(and bump the container tag to havefaasmctlinside the contianer), we also need to bump the mainfaasmtag.