Skip to content

Instantly share code, notes, and snippets.

@mpkocher
Last active October 2, 2019 15:06
Show Gist options
  • Save mpkocher/0332802048cad77078344aaa214b27a3 to your computer and use it in GitHub Desktop.
Save mpkocher/0332802048cad77078344aaa214b27a3 to your computer and use it in GitHub Desktop.
SMRT Link System and Test Dependencies

SMRT Link Dependencies

DOT Legend

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.

Notable Dependency Items

  • 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
convert:
dot -Tsvg -osmrtlink.svg smrtlink.dot
dot -Tpng -Gsize=9,15\! -Gdpi=300 -osmrtlink.png smrtlink.dot
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment