I'm sorry I don't understand the point of git clone. Here we simply install Functest via the python package. Pip install does a local copy because it's not published in PyPI yet and then removes it after installing the package.
Why should we clone again the repository? Cédric 2017-07-10 3:10 GMT+02:00 Beierl, Mark <mark.bei...@dell.com>: > Why should we avoid copy? Why do a git clone of the existing git clone? > Almost every dockerfile example I have seen uses copy, not a second got > checkout of the same code. > > Regards, > Mark > > *Mark Beierl* > SW System Sr Principal Engineer > *Dell **EMC* | Office of the CTO > mobile +1 613 314 8106 <1-613-314-8106> > mark.bei...@dell.com > > On Jul 9, 2017, at 21:00, Cedric OLLIVIER <ollivier.ced...@gmail.com> > wrote: > > No we cannot (parent directory) and we should mostly avoid copying files > (except for configurations). > > For instance, you could have a look to https://gerrit.opnfv.org/ > gerrit/#/c/36963/. > All Dockerfiles simply download Alpine packages, python packages (Functest > + its dependencies) and upper constraints files. > testcases.yaml is copied from host as it differs between our containers > (smoke, healthcheck...). > > Cédric > > > > 2017-07-10 1:25 GMT+02:00 Beierl, Mark <mark.bei...@dell.com>: > >> My only concern is for dockerfiles that do a "COPY . /home" in them. That >> means all the code would be located under the docker directory. >> >> I suppose multiple ../ paths can be used instead. >> >> Regards, >> Mark >> >> *Mark Beierl* >> SW System Sr Principal Engineer >> *Dell **EMC* | Office of the CTO >> mobile +1 613 314 8106 <1-613-314-8106> >> mark.bei...@dell.com >> >> On Jul 9, 2017, at 19:03, Julien <julien...@gmail.com> wrote: >> >> Hi Cédric, >> >> Patch in https://gerrit.opnfv.org/gerrit/#/c/36963/ is exact what I >> mean. Let's collect the opinions from the releng team. >> >> Julien >> >> >> >> Cedric OLLIVIER <ollivier.ced...@gmail.com>于2017年7月10日周一 上午4:15写道： >> >>> Hello, >>> >>> Please see https://gerrit.opnfv.org/gerrit/#/c/36963/ which introduces >>> several containers for Functest too. >>> I think the tree conforms with the previous requirements. >>> >>> Automating builds on Docker Hub is a good solution too. >>> >>> Cédric >>> >>> 2017-07-09 12:10 GMT+02:00 Julien <julien...@gmail.com>: >>> >>>> Hi Jose, >>>> >>>> According to the current implementation, current script only support >>>> one Dockerfile, my personal suggestion is: >>>> 1. list all the sub-directory which contains "Dockerfile" >>>> 2. build for each sub-directory fetched in #1 >>>> 3. for the names, in the top directory using the project name, in the >>>> sub-directory using: project_name-sub_directory_name >>>> not too much changes for current script and easy for project to manage. >>>> >>>> /Julien >>>> >>>> Beierl, Mark <mark.bei...@dell.com>于2017年7月7日周五 下午11:35写道： >>>> >>>>> Hello, >>>>> >>>>> Having looked over the docker-hub build service, I also think this >>>>> might be the better approach. Less code for us to maintain, and the merge >>>>> job from OPNFV Jenkins can use the web hook to remotely trigger the job on >>>>> docker-hub. >>>>> >>>>> Who has the opnfv credentials for docker-hub, and the credentials for >>>>> the GitHub mirror that can set this up? Is that the LF Helpdesk? >>>>> >>>>> Regards, >>>>> Mark >>>>> >>>>> *Mark Beierl* >>>>> SW System Sr Principal Engineer >>>>> *Dell **EMC* | Office of the CTO >>>>> mobile +1 613 314 8106 <1-613-314-8106> >>>>> mark.bei...@dell.com >>>>> >>>>> On Jul 7, 2017, at 11:01, Xuan Jia <jason.jiax...@gmail.com> wrote: >>>>> >>>>> +1 Using build service from docker-hub >>>>> >>>>> >>>>> On Thu, Jul 6, 2017 at 11:42 PM, Yujun Zhang (ZTE) < >>>>> zhangyujun+...@gmail.com> wrote: >>>>> >>>>>> Does anybody consider using the build service from docker-hub[1] ? >>>>>> >>>>>> It supports multiple Dockerfile from same repository and easy to >>>>>> integrate with OPNFV Github mirror. >>>>>> >>>>>> [1]: https://docs.docker.com/docker-hub/builds/ >>>>>> >>>>>> >>>>>> On Thu, Jul 6, 2017 at 11:02 PM Jose Lausuch < >>>>>> jose.laus...@ericsson.com> wrote: >>>>>> >>>>>>> Hi Mark, >>>>>>> >>>>>>> >>>>>>> >>>>>>> I would incline for option 1), it sounds better than searching for a >>>>>>> file. We could define specific values of DOCKERFILE var for each >>>>>>> project. >>>>>>> >>>>>>> >>>>>>> >>>>>>> /Jose >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* Beierl, Mark [mailto:mark.bei...@dell.com] >>>>>>> *Sent:* Thursday, July 06, 2017 16:18 PM >>>>>>> *To:* opnfv-tech-discuss@lists.opnfv.org >>>>>>> *Cc:* Julien <julien...@gmail.com>; Fatih Degirmenci < >>>>>>> fatih.degirme...@ericsson.com>; Jose Lausuch < >>>>>>> jose.laus...@ericsson.com> >>>>>>> *Subject:* Re: [opnfv-tech-discuss] Multiple docker containers from >>>>>>> one project >>>>>>> >>>>>>> >>>>>>> >>>>>>> Ideas: >>>>>>> >>>>>>> >>>>>>> >>>>>>> - Change the DOCKERFILE parameter in releng jjb so that it can >>>>>>> accept a comma delimited list of Dockerfile names and paths. Problem >>>>>>> with this, of course, is how do I default it to be different for >>>>>>> StorPerf >>>>>>> vs. Functest, etc? >>>>>>> - Change the opnfv-docker.sh to search for the named DOCKERFILE >>>>>>> in all subdirectories. This should cover the .aarch64 and vanilla >>>>>>> docker >>>>>>> file cases. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please +1/-1 or propose other ideas, thanks! >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Mark >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Mark Beierl* >>>>>>> >>>>>>> SW System Sr Principal Engineer >>>>>>> >>>>>>> *Dell **EMC* | Office of the CTO >>>>>>> >>>>>>> mobile +1 613 314 8106 <1-613-314-8106> >>>>>>> >>>>>>> *mark.bei...@dell.com <mark.bei...@dell.com>* >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Jun 24, 2017, at 04:05, Jose Lausuch <jose.laus...@ericsson.com> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> >>>>>>> >>>>>>> No need for an additional repo, the logic can be in Releng.. >>>>>>> >>>>>>> Functest will probably move to different containers some time soon, >>>>>>> so that is something we could also leverage. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -Jose- >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 23 Jun 2017, at 18:39, Julien <julien...@gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Agree, >>>>>>> >>>>>>> >>>>>>> >>>>>>> If StorPerf can list some rules and examples, current scripts can be >>>>>>> adapted for multiple docker image building and other project can use >>>>>>> this >>>>>>> type of changes. It is not deserved to add a new repo just for build a >>>>>>> new >>>>>>> image. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Fatih Degirmenci <fatih.degirme...@ericsson.com>于2017年6月21日周三 上午2:26 >>>>>>> 写道： >>>>>>> >>>>>>> Hi Mark, >>>>>>> >>>>>>> >>>>>>> >>>>>>> It is perfectly fine to have different build processes and/or number >>>>>>> of artifacts for the projects from releng point of view. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Once you decide what to do for storperf, we can take a look and >>>>>>> adapt docker build job/script to build storperf images, create >>>>>>> additional >>>>>>> repos on docker hub to push images and activate the builds when things >>>>>>> are >>>>>>> ready. >>>>>>> >>>>>>> >>>>>>> /Fatih >>>>>>> >>>>>>> >>>>>>> On 20 Jun 2017, at 19:18, Beierl, Mark <mark.bei...@dell.com> wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> >>>>>>> >>>>>>> I'd like to poll the various groups about ideas for how to handle >>>>>>> this scenario. I have interns working on breaking down services from >>>>>>> StorPerf into different containers. In one case, it will be a simple >>>>>>> docker compose that is used to fire up existing containers from the >>>>>>> repos, >>>>>>> but the other case requires more thought. >>>>>>> >>>>>>> >>>>>>> >>>>>>> We are creating a second container (storperf-reporting) that will >>>>>>> need to be built and pushed to hub.docker.com. Right now the build >>>>>>> process for docker images lives in releng, and it only allows for one >>>>>>> image >>>>>>> to be built. Should I be requesting a second git repo in this case, or >>>>>>> should we look at changing the releng process to allow multiple docker >>>>>>> images to be build? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Mark >>>>>>> >>>>>>> >>>>>>> >>>>>>> *Mark Beierl* >>>>>>> >>>>>>> SW System Sr Principal Engineer >>>>>>> >>>>>>> *Dell **EMC* | Office of the CTO >>>>>>> >>>>>>> mobile +1 613 314 8106 <1-613-314-8106> >>>>>>> >>>>>>> *mark.bei...@dell.com <mark.bei...@dell.com>* >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> opnfv-tech-discuss mailing list >>>>>>> opnfv-tech-discuss@lists.opnfv.org >>>>>>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss >>>>>>> >>>>>>> _______________________________________________ >>>>>>> opnfv-tech-discuss mailing list >>>>>>> opnfv-tech-discuss@lists.opnfv.org >>>>>>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss >>>>>>> >>>>>>> _______________________________________________ >>>>>>> opnfv-tech-discuss mailing list >>>>>>> opnfv-tech-discuss@lists.opnfv.org >>>>>>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> opnfv-tech-discuss mailing list >>>>>>> opnfv-tech-discuss@lists.opnfv.org >>>>>>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss >>>>>>> >>>>>> -- >>>>>> Yujun Zhang >>>>>> >>>>>> _______________________________________________ >>>>>> opnfv-tech-discuss mailing list >>>>>> opnfv-tech-discuss@lists.opnfv.org >>>>>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> opnfv-tech-discuss mailing list >>>>> opnfv-tech-discuss@lists.opnfv.org >>>>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss >>>>> >>>> >>>> _______________________________________________ >>>> opnfv-tech-discuss mailing list >>>> opnfv-tech-discuss@lists.opnfv.org >>>> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss >>>> >>>> >>> >
_______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
