Thanks for reply, in fact what I'm talking about is not the logic correct or not, but the efficiency.
Let's suppose we need to clone a big repo(may also submodules) for about 30 minutes, then what happened if we made a update in this repo? (NOTE: frequent changes in this repo)
Solutions maybe next:
1) Separate not frequently changed parts to base image, then every time we update, we could just build a small docker image. Disadvantage: We can't determine which parts not frequently changed, so can't use it.
2) In dockerfile, clone the big repo, then every time we had changes, we need to rebuild the docker image. Here we could not use docker build cache as we need the latest repo. Disadvantage: For a small change, we need another >= 30 minutes to clone & finally get a new docker image, not so agile.
3) In dockerfile, add/copy this when docker build, then a huge build context will be tar then pass to docker build container. Disadvantage: Tar the docker build context really consume time, also not agile.
4) In docker test shell of lava, when test begins, clone the resource. As `--rm` used, the big repo not be able to be reused by next time. Disadvantage: Every time when we trigger a new test job, we need wait > 30 minutes to wait the repo ready, then start the test.
5) Have bind mount there, every time, when we update code, we just need to pull/sync the changes, this finished in seconds. Then we start test job, no additional time for user to wait. Just first time, we need to clone the whole repo, it's a one-time effort.
So, sum all, what I care is efficiency.
-----Original Message----- From: antonio.terceiro@linaro.org antonio.terceiro@linaro.org Sent: Monday, June 8, 2020 10:25 PM To: Larry Shen larry.shen@nxp.com Cc: lava-users@lists.lavasoftware.org Subject: Re: [EXT] Re: [Lava-users] docker shell cannot handle adbd.
On Mon, Jun 08, 2020 at 01:24:47AM +0000, Larry Shen wrote:
Thanks Antonio for the clarify.
A side question: For docker test shell, if possible add more docker options for user? E.g. bind mount, etc.
A scenario is: If we have some code needed when test, currently, we could just inject it into docker image when do docker build, or when test git clone the code from network. You know docker test shell use `--rm`, means every time, we need to git clone it, or if a small changes we need to build the image. A bind mount there to mount our code may make things easier for us?
I'm not sure what is the problem you want to solve here. Including code in a docker image seems to be the recommended way of using docker. If the code changes, then the image changes - that's how it's supposed to work.
Note that the fact that docker runs containers with --rm has no effect on docker images: --rm only removes the _container instance_ after it finishes running, not the image. If your code was already in the image it's not affected. If the code is cloned during the test, it is also not affected by --rm as that same container instance would not be be reused for later tests anyway.