Skip to content

Dependencies management and project inheritance

To work with the RMK project’s repository, RMK needs to resolve and install additional dependencies that are described in the project.yaml file. The inheritance configuration of the upstream project’s repository is defined in the project.dependencies section of the project.yaml file. All inherited upstream project repositories will be loaded into the .PROJECT directory in the root directory according to the sections described in the project.yaml file.

To override inherited versions of dependencies and add-ons described in the inventory, you need to specify the entire block with all the required fields.

inventory:
  # ...
  hooks:
    helmfile.hooks.infra:
      version: v1.18.0
      url: git::https://github.com/<owner>/{{.Name}}.git?ref={{.Version}}
  # ...

Dependency resolution occurs when executing almost any RMK command, except for those in the rmk config command category.

Change dependency versions of the inherited project’s repository

Find the project section in the project.yaml file and change the version value to the needed stable tag. For example:

project:
  dependencies:
    # ...
    - name: <upstream_repository_prefix>.bootstrap.infra
      version: v2.17.0 # e.g., a different version of the dependency is required by this project
      url: git::https://github.com/<owner>/{{.Name}}.git?ref={{.Version}}
    # ...

Then, in the helmfiles section of the helmfile.yaml.gotmpl file the {{ env "HELMFILE_<project_name>_PATHS" }} environment variable will be used, this way RMK will manage the dependencies of the nested Helmfiles.

The variable name is formed according to the following template: HELMFILE_<project_name>_PATHS. This mechanism is necessary for resolving circular dependencies correctly.

Change inherited versions of Helmfile hooks

RMK allows to avoid controlling the versioning of the Helmfile hooks through the project.yaml file of the downstream project’s repository, instead of it, RMK allows inheriting these version hooks from the upstream project’s repository. It also supports multi-versioning of the Helmfile hooks as part of the inheritance from several upstream projects by a downstream project.

In order for these features to work, you need to use the HELMFILE_<current_project_name>_HOOKS_DIR variable in helmfile.yaml.gotmpl. For example:

commonLabels:
# ...
  bin: {{ env "HELMFILE_KODJIN_HOOKS_DIR" }}/bin
# ...

Let’s look at the following examples of the inheritance:

  1. Hook version inheritance from the upstream project’s repository:

    The project.yaml file of the downstream project is the following:

    project:
      dependencies:
        - name: kodjin.bootstrap.infra
          version: v4.4.0
          url: git::https://github.com/edenlabllc/{{.Name}}.git?ref={{.Version}}
        # ...
    

    In this case, a version of the Helmfile hooks in the inventory.hooks section is not specified, however, it is indicated that the current project of the repository inherits kodjin.bootstrap.infra with the v4.4.0 version. In turn, kodjin.bootstrap.infra inherits the deps.bootstrap.infra repository. The project.yaml file for the kodjin.bootstrap.infra repository is also missing the version of the hooks:

    project:
      dependencies:
        - name: deps.bootstrap.infra
          version: v2.19.0
          url: git::https://github.com/edenlabllc/{{.Name}}.git?ref={{.Version}}
        # ...
    

    Also, the project.yaml file of the deps.bootstrap.infra repository will contain the version of the Helmfile hooks, which will finally be inherited by the downstream project’s repository.

    inventory:
      # ...
      hooks:
        helmfile.hooks.infra:
          version: v1.18.0
          url: git::https://github.com/edenlabllc/{{.Name}}.git?ref={{.Version}}
      # ...
    

    There is no project.dependencies section in the project.yaml file of the deps.bootstrap.infra repository, since there is no inheritance.

    This configuration scheme is the most common and has the following inheritance scheme for the Helmfile hooks:

    Project repo name:            deps.bootstrap.infra ---------> kodjin.bootstrap.infra -------> <downstream_project>.bootstrap.infra
    Project repo version:         v2.19.0                         v4.4.0                          <downstream_project_version>
    Hooks repo name with version: helmfile.hooks.infra-v1.18.0 -> helmfile.hooks.infra-v1.18.0 -> helmfile.hooks.infra-v1.18.0
    
  2. Hook version inheritance from the upstream project’s repository in case the Kodjin project has a fixed version of the Helmfile hooks specified in its project.yaml file:

    The project.yaml file of the downstream project is the following:

    project:
      dependencies:
        - name: kodjin.bootstrap.infra
          version: v4.4.0
          url: git::https://github.com/edenlabllc/{{.Name}}.git?ref={{.Version}}
        # ...
    

    In this case, the version of the Helmfile hooks in the inventory.hooks section is not specified, however, it is indicated that the current project of the repository inherits kodjin.bootstrap.infra with the v4.4.0 version. In turn, kodjin.bootstrap.infra inherits the deps.bootstrap.infra repository which already has its own fixed version of v1.17.0 of the Helmfile hooks in the inventory.hooks section:

    project:
      dependencies:
        - name: deps.bootstrap.infra
          version: v2.19.0
          url: git::https://github.com/edenlabllc/{{.Name}}.git?ref={{.Version}}
    # ...
    inventory:
      # ...
      hooks:
        helmfile.hooks.infra:
          version: v1.17.0
          url: git::https://github.com/edenlabllc/{{.Name}}.git?ref={{.Version}}
      # ...
    

    The project.yaml file of the deps.bootstrap.infra repository will contain the version of the Helmfile hooks, which will be inherited by the downstream project’s repository:

    inventory:
      # ...
      hooks:
        helmfile.hooks.infra:
          version: v1.18.0
          url: git::https://github.com/edenlabllc/{{.Name}}.git?ref={{.Version}}
      # ...
    

    This configuration scheme will look like this:

    Project repo name:            deps.bootstrap.infra ---------> kodjin.bootstrap.infra -------> <downstream_project>.bootstrap.infra
    Project repo version:         v2.19.0                         v4.4.0                          <downstream_project_version>
    Hooks repo name with version: helmfile.hooks.infra-v1.18.0 -> helmfile.hooks.infra-v1.17.0 -> helmfile.hooks.infra-v1.18.0
    

    The downstream project’s repository will inherit the latest version of Helmfile hooks, specifically from the deps.bootstrap.infra repository. As a result, in the downstream project’s repository, we will have the two loaded versions of Helmfile hooks:

    • One will be relevant for the deps.bootstrap.infra repository and the downstream project’s repository.
    • Another will be relevant for the kodjin.bootstrap.infra repository.

    This mechanism allows for multi-versioning support of the Helmfile hooks at different levels of the inheritance.

  3. Hook version inheritance from the upstream project’s repository in case the downstream project has a fixed version of deps.bootstrap.infra specified in its project.yaml file:

    The project.yaml file of the downstream project is the following:

    project:
      dependencies:
        - name: deps.bootstrap.infra
          version: v2.20.0
          url: git::https://github.com/edenlabllc/{{.Name}}.git?ref={{.Version}}       
        - name: kodjin.bootstrap.infra
          version: v4.4.0
          url: git::https://github.com/edenlabllc/{{.Name}}.git?ref={{.Version}}
        # ...
    

    The dependencies should be declared in the correct order of inheritance: the first one is deps.bootstrap.infra, then kodjin.bootstrap.infra, then other repositories (if needed).

    In this case, a version of the Helmfile hooks in the inventory.hooks section is not specified, however, it is indicated that the current project of the repository inherits kodjin.bootstrap.infra with the v4.4.0 version. In turn, kodjin.bootstrap.infra inherits the deps.bootstrap.infra repository. The project.yaml file for the kodjin.bootstrap.infra repository is also missing the version of the hooks:

    project:
      dependencies:
        - name: deps.bootstrap.infra
          version: v2.19.0
          url: git::https://github.com/edenlabllc/{{.Name}}.git?ref={{.Version}}
        # ...
    

    The project.yaml file of the deps.bootstrap.infra repository of the v2.20.0 version will contain the version of the Helmfile hooks, which will be inherited by the downstream projects:

    inventory:
      # ...
      hooks:
        helmfile.hooks.infra:
          version: v1.19.0
          url: git::https://github.com/edenlabllc/{{.Name}}.git?ref={{.Version}}
      # ...
    

    This configuration scheme will look like this:

    Project repo name:            deps.bootstrap.infra ---------> kodjin.bootstrap.infra -------> <downstream_project>.bootstrap.infra
    Project repo version:         v2.20.0                         v4.4.0                          <downstream_project_version>
    Hooks repo name with version: helmfile.hooks.infra-v1.19.0 -> helmfile.hooks.infra-v1.19.0 -> helmfile.hooks.infra-v1.19.0
    

    Since the downstream project’s repositories inherit the Helmfile hooks from the deps.bootstrap.infra repository, and we redefined the deps.bootstrap.infra dependency in the downstream project’s, all repositories will inherit this concrete version, and only it will be downloaded.

Change inherited versions of clusters, Helm plugins, tools

The same inheritance method as for the Helmfile hooks is supported for inventory sections as clusters, helm-plugins and tools. If a specific version is not specified, the latest version from the upstream project’s repository will always be used, with one exception only: in this case, multi-versioning is not supported, and only one version will be downloaded.

All add-ons versions in the inventory sections must be specified in the SemVer2 format, as the inheritance mechanism relies on this format to distinguish the version order.


Last update: August 20, 2024