Hi Chad,
Thank you for the feedback.
> Personally I don't think what you are trying to do is compatible with the conceptual design goals of either git or GoCD. If these various paths are really independent of one another and cannot be looked at within the scope of the wider repo or organised into a "simple" mono repo structure, should they possibly be independent repositories?
Part of our struggle is that we are moving from a TFVC-based monorepo to a set of slightly more segmented Git repos. TFVC allows checking out any arbitrary section of the file tree and the above materials are direct translations of the existing TFVC materials into Git-path materials. (I.E., the App Git repo is an export of TFVC path "$/Project/path/to/App" and the existing materials pull from "$/Project/path/to/App/Trunk" and "$/Project/path/to/App/Documents/Spec".)
In terms of cross-repository code, what I mean is that if I am working with an app that lives at ./Apps/App1, the project for this code is structured in such a way that it assumes someLib exists at ../../Libs/someLib/bin (relative to my App1 directory). This relative path is accurate within the TFVC monorepo, but with the move to Git, someLib has been moved into a separate Git repo. In order to ensure the builds continue to work without having too much impact on the developer workflow, we need to recreate that same relative pathing at checkout time.
Realistically, we probably should work with the development team to come up with some new workflows that are more aligned with Git and code separation principles, but the objective of our current initiative is to modernize our tech stack as cheaply as possible. In practical terms, that means we are primarily looking to recreate our existing workflows using the current version of GoCD (instead of 19.8.0), backed by Git on Azure DevOps rather than TFVC on TFS Server 2013.
I think you are probably right and the only sane way of tackling this for now is to use no more than one git-path material for any given Git repo on a pipeline. I will have to think a bit on how to sanely name the materials to ensure that:
- When 2 pipelines should share a material, it is easy to give it the same name in both YAML files, and
- There are no naming conflicts between multiple pipelines that need different slices of any given repo.
Thank you again for taking the time to respond. As always, your insights are appreciated.
Cheers,
Jason