Hello 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 Thanks -Anthony -- 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 https://groups.google.com/d/msgid/go-cd/f6738e29-459a-4f7f-a0c4-1fb209f35cdf%40googlegroups.com.
