Summary
We're pleased to announce the release of Commodore v1.4.0.
Apart from dependency updates, this release adds support for using Commodore dependencies (components or packages) in a sub-path of a repository, adds support for having multiple Commodore dependencies stored in the same repository, improves support for managing configuration packages, and adds a lint for deprecated Kubernetes API versions to the component template.
Dependency management
To enable users to provide dependencies (components or packages) in a sub-path of a repository, Commodore now supports a new optional key `path` in dependency specifications (the entries in `parameters.components` or `parameters.packages` respectively). If the key `path` is not present, Commodore assumes that the dependency is stored in the repository root. When a sub-path is given, Commodore will ensure that the contents of that sub-path are made available in the Kapitan inventory.
Also, in order to support packages which are stored in a sub-path of a repository, Commodore now downloads packages to `dependencies/pkg.<package-name>` and symlinks them to `inventory/classes/<package-name>` instead of directly cloning packages into `inventory/classes`.
Additionally, Commodore now uses [Git worktrees](https://git-scm.com/docs/git-worktree) to manage the component and package checkouts in `dependencies/`. This allows Commodore to clone each dependency repository exactly once, regardless of the number of dependencies stored in the repository.
When you run Commodore in an existing working directory, it will attempt to migrate your existing dependency checkouts to the new worktree-based checkouts, but will abort if it might delete any local data (uncommitted changes, untracked files, and local branches which don't exist in the remote repository are treated as local data).
Package boilerplate updates
Commodore provides a new command `package update`, which allows users to update their existing configuration packages from the configuration package Cookiecutter template. We also added support to `package update` to allow users to add new test cases or remove test cases from an existing package as well as modifying some other selected values in the package boilerplate.
Component linting
This release also adds support for linting components with [`kubent`](https://github.com/doitintl/kube-no-trouble) to the component template. This lint warns component authors about Kubernetes API versions which are deprecated or will be deprecated soon. Due to how the tool works, we've not added this new lint to the component GitHub actions, and instead only provide a make target to run the lints locally at this time.
Changes