Shape (and Color) | Description |
---|---|
RECT DOTTED | Third party dependency |
OVAL GREEN | Build Output |
RECT | BitBucket Repo |
DIAMOND PURPLE | SMRT Link Service Subcomponent (to the SL Services Core Component) |
HEXAGON AQUA | SMRT Link Core Subcomponent |
DOUBLE HEX BLUE | SMRT Link System |
In this model, the SL_services_slag
is approximately the current "pbbundler" + "smrtslag" components.
The installer has dependencies on the tools within the current "pbbundler". This is not cleanly captured in here. Perhaps, SL_subservices_slag
-> SL_installer
captures the dependency? This is mixing up the build time vs run time dependencies.
The smrtflow component emits two overlapping sets of tools. One at the "SLAG" layer, and one at the "tools" layer. In the current system, generates two versions of some commandline tools (e.g., pbservice) in the SMRT Link System master build.
- The SHA from pbsmrtpipe must be the same in both the SMRT Link Tools and SMRT Link Services Core components via Resolve Pipeline Template JSON Files
- The SHA from smrtflow must be the same in the SL Tools and SL Services