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.

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.

Reply via email to