On Wed, Apr 7, 2021 at 12:22 AM Kadu Barral <[email protected]> wrote:
> There are any news about this in the last 6 years? > Same case here, we are working with golang microservices and pipelines are > about the same GENERATE PROTO (with make) > BUILD GO BINARY (make) > BUILD > DOCKER IMAGE > UNIT TEST (make) > DEPLOY (kustomize) > > There are any way to use the same pipeline with different materials? > Each microservice is one repo in github. > I have used Templates for this - where we create a template with the flow that you describe, and then create pipelines per template with materials per pipeline. I've used the XML configuration approach. -- Ram > > Thanks > A segunda-feira, 7 de março de 2016 à(s) 14:12:38 UTC, > [email protected] escreveu: > >> Is there a way to get a generic pipeline that can take material url as >> parameter. Since we have microservices and each is linked to a repository >> and we have one pipeline per repository. >> ended up many. >> DevOps worried about the maintenance. >> Any suggestion ? >> >> >> On Tuesday, April 28, 2015 at 8:05:10 PM UTC+2, Jaz Chana wrote: >>> >>> I think you are right and normally that's exactly what I would do. >>> What's different here is that we have a series of 'micro-services' that >>> have identical project structures and build lifecycles. A change in one >>> will result in a change in the the others, >>> >>> For now I think I'll just bite the bullet and create the 15 individual >>> build pipelines. >>> >>> On Mon, Apr 27, 2015 at 11:13 AM, Radoslav Minchev < >>> [email protected]> wrote: >>> >>>> yeah, that's an option, I still think that a better separation of >>>> concerns is always a good choice when a project(s) grow. >>>> >>>> Best, >>>> Rado >>>> >>>> On Monday, April 27, 2015 at 1:05:48 PM UTC+3, Jaz Chana wrote: >>>>> >>>>> I the way I was thinking it could work is, I could check-in project A >>>>> and while thats building check-in project B and have two separate >>>>> instances >>>>> of the pipeline running, for each project. This way they would then not be >>>>> dependant on each other and a failure in one instance would not result in >>>>> a >>>>> failure to build another instance. >>>>> >>>>> On Sun, Apr 26, 2015 at 4:19 PM, Radoslav Minchev < >>>>> [email protected]> wrote: >>>>> >>>>>> It's an interesting scenario, but if all these are really different >>>>>> projects I would prefer to have better control on them by having a >>>>>> "build" >>>>>> pipeline per project. I don't want if project A fails to affect the rest >>>>>> of >>>>>> the projects. >>>>>> >>>>>> my 2 cents. >>>>>> -rado >>>>>> >>>>>> On Wednesday, April 15, 2015 at 7:13:35 PM UTC+3, Jaz Chana wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I have multiple projects that are all compiled, tested and built in >>>>>>> the same way. In summary I want to be able to build and test all of >>>>>>> these >>>>>>> projects in the same way and not block any of the projects from each >>>>>>> other >>>>>>> when doing this. For example, if I make a change to project A and B and >>>>>>> check-in at the same time I want to test and build them on go server at >>>>>>> the >>>>>>> same time. >>>>>>> >>>>>>> An easy way to do this is to create a pipeline for each of the >>>>>>> applications, e.g. Pipeline A, Pipeline B, each with its own material >>>>>>> (svn >>>>>>> repo). However there are 15 applications and I don't want to have to >>>>>>> repeat >>>>>>> this configuration in 15 Pipelines. So I thought an easier way to do >>>>>>> this >>>>>>> would be to create a template and then 15 pipelines that use that >>>>>>> template. >>>>>>> So the bulk of the configuration is all in one template. However I'll >>>>>>> still >>>>>>> have 15 pipelines and there will be some configurations required in >>>>>>> each. >>>>>>> >>>>>>> Is there a way to achieve the above using a single pipeline but with >>>>>>> multiple materials? >>>>>>> >>>>>>> The other reason I want to do this is because I want to be able to >>>>>>> deploy to same bucket in s3 (useing the go-cd s3 plugin). For example I >>>>>>> want projectA.war and projectB.war to be published >>>>>>> to go-artifacts/pipeline/published/artifacts/1.1. >>>>>>> >>>>>>> Any help would be appreciated. >>>>>>> >>>>>>> Cheers >>>>>>> Jaz >>>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to a topic in >>>>>> the Google Groups "go-cd" group. >>>>>> To unsubscribe from this topic, visit >>>>>> https://groups.google.com/d/topic/go-cd/2ETiT-zgr0w/unsubscribe. >>>>>> To unsubscribe from this group and all its topics, send an email to >>>>>> [email protected]. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> -- >>>> You received this message because you are subscribed to a topic in the >>>> Google Groups "go-cd" group. >>>> To unsubscribe from this topic, visit >>>> https://groups.google.com/d/topic/go-cd/2ETiT-zgr0w/unsubscribe. >>>> To unsubscribe from this group and all its topics, send an email to >>>> [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- > You received this message because you are subscribed to the Google Groups > "go-cd" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/go-cd/977a45ed-cfa9-4851-88e0-6286b3fd02a1n%40googlegroups.com > <https://groups.google.com/d/msgid/go-cd/977a45ed-cfa9-4851-88e0-6286b3fd02a1n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "go-cd" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/CANiY96YCGmGquELy9i_rUt%3DcU3cbxt-aX%2BHuw%3DrRUTE3Wu0A6A%40mail.gmail.com.
