On Tue, Feb 16, 2016 at 2:15 PM, Bamacharan Kundu <bamachrn at gmail.com> wrote: > Hi Vašek, > Yes, I have created pipeline with a nodejs based application( > https://github.com/bamachrn/cccp-demo-test) > with openshift build system. Openshift template is taking the git repo > URI as input, and building, testing within the containers. > As a output this is pushing the ready to run containers to the registry. > > Went through the atomic reactor for reading index.yaml and cccp.yaml > written by rtnpro, kbsingh. > > I am currently working to understand the openshift template and build > config to automate the build > on git push or scheduled time. > Feel free to shoot questions, I've spent quite some time figuring out how these work:) > > Today I am trying to trigger with Github webhook. This is not triggering > the build due to my IP being in private network. > also waiting for the ci.centos.org access to use jenkins in build process. > Yeah, you'll need a public IP/DNS name to be able trigger hooks, I don't think there is a workaround for this (well, apart from running your own gitlab on the same machine or something like that) > > Please suggest if there is another way to achieve this. > > Thanks > Bamacharan > Cheers, Vašek > > On Tue, Feb 16, 2016 at 6:29 PM, Vaclav Pavlin <vpavlin at redhat.com> wrote: > >> Hey, any progress here? >> >> Vašek >> >> On Wed, Feb 10, 2016 at 4:19 PM, Vaclav Pavlin <vpavlin at redhat.com> >> wrote: >> >>> >>> >>> On Wed, Feb 10, 2016 at 3:33 PM, Bamacharan Kundu <bamachrn at gmail.com> >>> wrote: >>> >>>> 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. >>>> >>> >>> To un-confuse people who didn't see our IRC convo - the Dockerfiles in >>> cccp-demo-openshift repo represent containers which implement individual >>> steps of the workflow - not the images/containers which are tested and >>> delivered. >>> >>> To answer "Why don't we take a layered based aproach": We do, building >>> from Dockerfile follows the layered approach. The problem I am trying to >>> emphasize is that we need clean environment for every build, otherwise we >>> could introduce inconsistency again..But I think this could be easily >>> solved by using Atomic Reactor instead of my custom hacky script:-) >>> >>> >>> Cheers, >>> Vašek >>> >>>> >>>>> >>>> >>>>> 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/ >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >>> >> >> >> -- >> 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/ > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20160216/68e2bb10/attachment-0008.html>