Linking a "master" parts.yaml file across projects

Hi everyone,

I’m a new user of GitBuilding and am looking into using it for device assembly instructions for the non-profit I work for (Makers Making Change). We have a lot of devices that use the same parts, so I was wondering if it is currently possible to have a “master” parts.yaml file that multiple projects can pull from so if we make a change on that “master” it will automatically propagate through all the projects that pull from it.

2 Likes

Great question. Better library management is certainly something GitBuilding needs to work on.

I think that while there are no built in options for this in GtBuilding it may be possible depending on what technology you are using to store/share the documentation.

If it is on one local machine you might be able to do it with the external directories feature of GitBuilding, or via a symbolic link. If it is in Git, then you could put the parts.yaml in its own repository and then including it as a Git submodule.

Neither of these are great solutions, but they might get you started.

How would you like it to work in GitBuilding as we plan this feature? Perhaps in the configuration being able to point to the URL of a file and specify where that should be pulled to locally before build?

Thanks for the quick response! We currently collaborate using both Microsoft 365 products (Sharepoint/Teams folders) and GitHub. We post all our finished devices to GitHub to host them, so I think the Git submodule sounds like a good option for us for now.

I think your suggestion of pointing to the URL of a file would work well. Are you imagining that as you create a master GitBuilding project that has the master parts.yaml you’d then edit, or just host the parts.yaml however works best for someone (in another Git repo or something like that)?

I don’t have a fully formed idea. It wouldn’t be a master project, but just a yaml file of parts on the web. This way in theory different people in the community could maintain different parts lists, such as generic lists of all screws, or lists of stepper motors, or lists of bearings, etc etc.

In your config you could then do something like:

fetch-external:
    parts/screws.yml: https://website.web/libs/screws.yml
    parts/bearings.yml: https://different.website/gitbuilding/bearings.yml

This same syntax may allow other files such as assembly instructions or images to be pulled in externally. It would open up a lot of potential for open collaboration and reusing sub-modules. However, it does open up more risk to that the linked content may go offline.

That makes a lot of sense, yeah!

If we continue with GitBuilding for our documentation I’d be happy to try to set something up where we’d host .ymls for the parts we used.

Thanks again!

1 Like