I am curious what is the best practice is for the following scenario:

Library A is used by Program B via an External Artifact Repository 
(nuget.org, npm, etc)

It seems like a 'simple scenario involving 2 pipelines:

Pipeline A (Library)
Source -> Build -> Test -> Deploy Artifact

Pipeline B (Program that use Library A)
Source -> Build -> Test -> Deploy To Production

In this example, there is no 'GoCD dependency' between pipeline A and B.  
If A's source is changed, A.2 is built and eventually deployed to the 
External Artifact Repo.   In order for program B to use it, source code is 
edited (ie C# packageReference or Package.json) to link to the A.2.  A new 
build B.2 is generated and if it passes, it is deployed.  The VSM for 
Pipeline B.2 has no indication that Pipeline A.2 was involved / consumed.

It feels like the Up / Down stream + Package Repo along with the VSM 
capabilities of GoCD should be able to handle this scenario.  However, in 
my experimentation, things break down due to fact that the build has to 
modify a file under source control that tells Program B to switch from  
Library A.1 to A.2.  Changing the file locally during the build stage seems 
like cheating since this won't become part of the official source history.  
(version control of the library references is very important)

Like above the example above, all of my pipelines are 'silos'  If i want to 
deploy a new version of the top most dependency, I have to do a lot of 
source code changes to propagate a version bump downstream manually.  Now 
granted this is extremely 'safe' since the change might be breaking - it 
just can be very time consuming if there are 20 downstream projects.  If 
this were automated I could in theory publish a new 'top-level' dependency 
and have the entire downstream build process detect any breaking changes 
via build or test failures.

In addition automation, for any built (or deployed) artifacts, I would want 
to see a VSM that shows the state of all upstream pipelines that were 
involved / consumed so I can see at a glance what upstream labels are part 
of a downstream artifacts.  

1. Does GoCD have a way of showing / managing these type of dependencies?

2. Does GoCD have a way to bump versions (change source code) references to 
match upstream labels? Or is this burden on me?  

3. Are all upstream pipeline labels available as environment variables to 
downstream pipelines?  
(I could in theory create a parallel dependency pipeline - which does 
nothing but bump versions. However, the further downstream, the wider the 
scope of version bumping becomes as C depends on B and A, not just B 
depends on A)

In any case, was curious if some how the current functionality of GoCD 
addresses the above, or is this a separate 'feature / enhancement


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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Reply via email to