Hi Vaclav, On Wed, Feb 10, 2016 at 6:53 PM, Vaclav Pavlin <vpavlin at redhat.com> wrote: > Hi Bamacharan, > > I'd be careful with per commit builds in case of build from Dockerfile as > it takes time and resources (presumably a lot of both) because we have to > build in clean env and with --no-cache. > Why don't we take a layered based aproach, we can take the base image from local system then build it, this will save lot of time? I saw multiple dockerfiles for build,test,delivery which are intern the same image only. > > > I am not sure what you mean by " built image would be deployed to > openshift instance". > I was saying about building the docker container images in openshift for the build, test, delivery environments. > > My idea would be to go with the yaml files I saw in cccp-index and > rtnpro's example repo as an UI right now - keep the code as little as > possible. Hook it up to my example with some scripting, setup OpenShift and > registry and try to get whole workflow working. > Yes, I was going through the same. I tried with building the example you have put. I am going through the cccp-index and yaml file to add with the example you have put. > > > I as a developer want to add a yaml file to my repo and submit my repo url > somewhere, so that it gets rebuilt, tested and pushed to a given registry > regularly (like 4 times a day for start). I also want to be notified about > new build and test results. > Yes, this yaml will help to handle all the linking and container management stuff. > > Done:-) We can polish it later. > > Makes sense? > > Sure, going ahead with this. Regards Bamacharan > > On Wed, Feb 10, 2016 at 12:47 PM, Bamacharan Kundu <bamachrn at gmail.com> > wrote: > >> >> >> On Wed, Feb 10, 2016 at 4:30 PM, Karanbir Singh <kbsingh at centos.org> >> wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 10/02/16 07:29, Bamacharan Kundu wrote: >>> > Hi, >>> > >>> > Vaclav presented the build pipeline very nicely and this would >>> > take out lot of tension for building the code, checking the code >>> > standards and test cases from the developer. >>> > >>> > I would like to add few points on this. >>> > >>> > On Tue, Feb 9, 2016 at 8:08 PM, Vaclav Pavlin <vpavlin at redhat.com >>> > <mailto:vpavlin at redhat.com>> wrote: >>> > >>> > >>> > Hi all, >>> > >>> > As KB wrote, I brought up the idea of using OpenShift as a glue >>> > (i.e. workflow controller). The result can be found here: >>> > >>> > https://github.com/vpavlin/cccp-demo-openshift >>> > >>> > TL;DR: >>> > >>> > The repository contains OpenShift Template defining the workflow - >>> > build,test, delivery and (very poorly) implements the steps through >>> > Docker images (i.e. Dockerfiles and run scripts). >>> > >>> > The developer should do only git push to his VCS and this should >>> > trigger the build process in the pipeline. >>> >>> in an onprem story that would map well, but note that were aiming to >>> run a hosted service with a distinct UI ( even if the UI is no UI ) >>> >> >> Yes, now I got it. I had a thought to minimize the number of Dockerfiles, >> so that the user does not get confused of. >> >>> >>> > >>> > In this TDD process all the environments (including the build, >>> > test, delivery) would be created as a container and once the step >>> > is over it will destroy the environment. As output this will >>> > generate a application runtime along with the successfully built >>> > application code to registry. >>> > >>> > As you mentioned this would be tagged with test along with jenkins >>> > build id, so that developer or QA can trace for which commit this >>> > is built. >>> > >>> > Then for the next stages, successfully built image would be >>> > deployed to openshift instance to get through the test, delivery >>> > stages checking, along with the quality gates. >>> > >>> > all the stages should be linked to pipeline and should be easily >>> > re-producible so that any one can check or regenerate the issues >>> > instantly. >>> >>> add another dimension there - collection of related containers, ie. >>> the entire microservice should be reproduceable. >>> >>> This means system needs to maintain all the linking and volume sharing >> of the components. >> >>> > >>> > It's easily runnable in Vagrant with use of Project Atomic >>> > Developer Bundle. >>> > >>> > If you are interested in more info, I'd suggest to read the readme >>> > in the repo, I hope it summarizes it clearly. >>> > >>> > It's a very minimal demo, but I think it suggests the path, which >>> > could take us to the Unicorns land, quite well:). >>> > >>> > Let me know in case of any questions, suggestions or requests for >>> > guidance in case anybody decides to take this further. >>> > >>> > I would like to take this further, please let me know if my >>> > thought process is in the same line as yours or any changes, >>> > suggestions. >>> >>> we need to work through whats needed to now integrate with the >>> cccp-index content, and then map that back to deliverables. I had >>> asked Zeeshan to look at registry side for delivery space, unsure how >>> far he's gotten with that. >> >> >> I believe, I should look for integration with cccp-index content? >> >> Regards >> Bamacharan >> >> -- >> Bamacharan Kundu >> IRC Nick- bamachrn >> http://bamacharankundu.wordpress.com/ >> >> _______________________________________________ >> CentOS-devel mailing list >> CentOS-devel at centos.org >> https://lists.centos.org/mailman/listinfo/centos-devel >> >> > > > -- > Developer Experience Team > Brno, Czech Republic > Phone: +420 739 666 824 > > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > > -- Bamacharan Kundu IRC Nick- bamachrn http://bamacharankundu.wordpress.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20160210/15494bbe/attachment-0008.html>