projectsyn/commodore

Add support for dependencies in a subdirectory of a monorepo

simu opened this issue · 3 comments

simu commented

Context

Some software is developed in a monorepo which contains both the source code and any required configuration templates (e.g. Helm charts) required for deploying the software.

While it's technically already possible to use a config package in a subdirectory of a repository, it's not very ergonomic as any class includes of such a package would have format <package-name>.path.in.repo.<class-name>. For such software, it would be nice if Commodore's config package support would allow users to specify a path within the Git repository where the actual config package is stored. This would allow users to include classes of such a package using the usual <package-name>.<class-name> format.

Implementation-wise, this could be supported by introducing an additional key path for the package specifications in parameters.packages.

Acceptance criteria

  • Commodore supports an additional optional key path for dependency specifications. If the key is not present, the whole repo is used as the dependency, otherwise the subdirectory in the repo indicated by path is used as the dependency.
  • Both components and packages in a repository subdirectory are supported

Alternatives

Keep as is, let users deal with the inconvenient class names of such packages

Implementation ideas

  • Fetch repos into packages in the working directory and symlink actual package(s) to inventory/classes
  • Fetch repo only once if multiple packages are stored in different subdirectories
simu commented

Keep in mind that a repo might have multiple packages in different directories for implementation (i.e. deduplicate repo clones/fetches)

simu commented

We'll have to somehow handle the case where multiple dependencies in the same monorepo are included with different versions. Either we'll have to clone the repo separately for each dependency, or we'll have to figure out how to make use of git worktree.

ccremer commented

For a first iteration I'd be happy if the repo is shallow cloned for each dependency.
I don't know how it'll work with tags though.

Usage example how a monorepo release and tag scheme could look like:

  • vx.y.z for normal code/image tags
  • <chart-name>-x.y.z for chart version tags (which might be different than code tags, and there could be multiple charts)
  • component-x.y.z for component version tags

The tags could be built up on eachother, e.g. component-1.0.2 refers to a tag chart-2.3.5, which refers to docker image v1.2.1.

(A shallow clone of component-x.y.z would contain the full component with all the chart and image versions pinned)

However, another example of a monorepo would be consolidation of similar components and/or config packages for maintenance reasons. For example (tags):

  • component-prometheus (component-v2.4.5)
  • package-prometheus-openshift4 (pkg-ocp4-v1.0.0)
  • package-prometheus-rancher (pkg-rancher-v1.1.1)