Open MariusStorhaug opened 2 years ago
Not worked with submodules, but can imagine that tool support (intellisense) is something you would need to strive to set up manually to get working, with checking out the repo on local machine + having to reference a specific tag of the module.
I think adding guidance around consuming CARML as a git submodule is a great idea.
You're basically looking at something like the following.
from within in your target (consuming) repo
git submodule add https://github.com/Azure/ResourceModules microsoft-carml
cd microsoft-carml
git checkout tags/v0.5.0 # Pick latest release version
then commit and push.
In the future if you want to move to another release version you'd simply:
cd microsoft-carml
git checkout tags/vNew.Latest.Version
then test (and make adjustments to your consuming code if needed), commit and push.
This isn't a sparse checkout, meaning you'll get the whole of the CARML modules. But in that that way you can treat it like any third party/vendor dependency.
cc: @alex-lee-microsoft
Just noticed this issue and as we are actually consuming the modules as a git submodule and I recently wrote a short description of the process, just throwing this in here as an example. This approach has worked for us so far, but obviously there are some pain points like what to do with modules that lack some functionality that we'd need (say, APIM and private endpoints).
Description
Add guidance on how CARML could be used when referencing it as a git submodule. What are the pros and cons.
Ref: Working with submodules | GitHub Blogs