Force pipeline material to run

[Ertan Küçükoglu]

Hello,

I am *very* new to GoCD. Just set it up today in a couple hours ago.

I always would like to trigger all my pipelines manually. There are some pipelines that I would like them to run after another pipeline. For example, There is an "update" application which is in a subversion repository. There is also "app1" application in another subversion repository.

My main purpose is to build "app1" but it also needs "update" so I would like "update" pipeline to run automatically from scratch whenever I trigger "app1".

I setup myself single group and two pipelines in it as follows.

Pipeline1 "update"

Pipeline2 "app1"

Pipeline2 has Pipeline1-BuildStage linked in its material tab.

When I run Pipeline2, I would like to force run Pipeline1 completely. What I mean by "completely" is as if I manually triggered pipeline1 run button on the dashboard.

I could not do that for now.

I think GoCD check Pipeline1 and see it is built successful and it is set to manual triggering and does not run it at all.

I read documents and made some google searches, but no luck. I believe I am missing something.

Any help is appreciated.

Thanks & Regards,

Ertan

[Ashwanth Kumar]

GoCD can't trigger upstream pipelines by design. 

The artifacts should ideally flow downwards (eg: from build -> dev -> staging -> prod) and not the other way around. You can set up pipelines such that if you trigger Pipeline 1 and it passes, it can trigger Pipeline 2 and so on. 

In your case if you've update1 as a dependency of app1, why not have them in a single pipeline as 2 stages where you run update in the first stage and app1 in the second? 

Thanks,

--
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 go-cd+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/d4dc059a-c025-4574-b288-f6feeef47bb6n%40googlegroups.com.

--

Ashwanth Kumar / ashwanthkumar.in

[Ertan Küçükoglu]

Thanks for your reply.

I have "update" as an application which used in several more applications other than "app1" so I wanted to have it as a separate build of its own. Since I will be manually triggering builds, I also wanted it to build from scratch by getting sources and everything.

If I reverse my design, "update" will be linked to multiple pipelines (which will be other applications in my case). Having them all linked will also mean that I will be triggering all other applications' builds as I must first run "update" and it will run other linked pipelines. This would be something I do not want.

Maybe, I should add "update" as another build stage. But, I need to manually add stages to each pipeline where it is used. If I need to change a build parameter later, I have to manually modify all relevant stages where it is used. This was something I wanted to prevent by having a separate pipeline for "update".

I need to think about it.

Regards,

Ertan

16 Mart 2023 Perşembe tarihinde saat 23:18:13 UTC+3 itibarıyla ashwant...@gmail.com şunları yazdı:

[Ashwanth Kumar]

If "update" is an application (I am reading it as a shared library) that is needed by other downstream systems, then your current design makes sense. Having said that, why would you want to re-trigger a new run of "update" for each new run of the downstream system(s)? That part doesn't make sense, because if this "update" needs to be triggered for each "app-N" system(s) then it's not really a shared library but a configuration repository or a deployment script that every downstream system needs isn't?  

If you still want to make sure you always take the latest changes of "update" may be run the pipeline on Timer (may be every 1 hour or 15 minutes) depending on how soon the changes you want. Yes it's wasteful of resources, but so is manually automating the workflow by modelling the pipelines this way. I would ask myself which of the following would I be using 80%+ of the time:

1. A fully automated setup for building and deploying each application (Assuming each service owner would be able to manage that on the long run) 
2. Modifying the build parameters of "update" frequently

Thanks,

To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/e74fc173-3800-4f53-a36a-feef7f16f558n%40googlegroups.com.