# Commands

## Catalog Compile

`commodore catalog compile CLUSTER`

This command compiles a cluster catalog. This is the main mode of operation for Commodore when managing clusters.

This command will first collect all required components and hierachical configuration and prepare the inventory for Kapitan.

Then, the command will process the compiled inventory, and create secret references in `catalog/refs/` for any secret references it finds in the inventory.

After the inventory and all references are in place, Kapitan is called to render the templates as specified by the compiled inventory.

After Kapitan has rendered all templates, any defined postprocessing filters are applied to the output of Kapitan, before the fully processed manifests are copied into the cluster catalog at `catalog/manifests/`.

## Catalog Clean

`commodore catalog clean`

This command deletes all the data which is managed by Commodore, listed below.

• the downloaded and potentially modified catalog in `catalog/`

• all the downloaded and potentially modified components in `dependencies/`

• the generated inventory in `inventory/`

• Kapitan’s output in `compiled/`

This command doesn’t check whether any local modifications exist and doesn’t check with the user whether they really want to remove the items listed above.

## Component New

`commodore component new SLUG`

This command creates a new component repository under `dependencies/` in Commodore’s working directory. The component repository is created using a Cookiecutter template which provides a skeleton for writing a new component. The command requires the argument `SLUG` to match the regular expression `^[a-z][a-z0-9-]+[a-z0-9]$`. Optionally, the template can be used to add a component library and postprocessing filter configuration. The command expects to run in a directory which already holds a Commodore directory structure. The command makes sure to create symlinks for the new component’s classes and creates a new Kapitan target for the component. The command also adds the new component as a dependency in `jsonnetfile.json` and runs jsonnet-bundler to symlink the new component into `vendor/`. The template also provides many meta-files in the component repository, such as the readme and changelog, standardized license, contributing and code of conduct files, a documentation template, and GitHub issue templates and actions configuration. ## Component Delete `commodore component delete COMPONENT_NAME` This command removes a component directory from under `dependencies/` in Commodore’s working directory. The command will require confirmation before performing destructive operations, unless it’s passed the `--force` option. The command expects to run in a directory which already holds a Commodore directory structure. The command makes sure to remove symlinks for the new component’s classes and deletes the Kapitan target for the component. The command also removes the deleted component as a dependency in `jsonnetfile.json` and runs jsonnet-bundler to remove the symlink to the deleted component in `vendor/`. ## Component Compile `commodore component compile PATH` This command compiles a single component. This is the main mode of operation for developing new components, as it allows fast iteration while working on a component. This command will create a fake inventory which mocks out all the infrastructure which a component would expect to be available when it’s included in a cluster’s configuration. The command takes so called values files which provide custom configuration values for any configuration that could be provided from the hierarchical configuration repositories. The option `--alias` (or `-a`) can be used to compile an instance-aware component with a specific instance. ## Inventory Components `commodore inventory components GLOBAL_CONFIG [TENANT_CONFIG]` This command lists all the components defined in `parameters.components` in the Commodore hierarchy in directory `GLOBAL_CONFIG`. If provided, the command also takes into account the tenant repo in directory `TENANT_CONFIG`.  The command doesn’t currently support cloning either the global or tenant repository from a Git repo URL. The component takes a repeatable argument `-f / --values` which allows the user to specify additional files that should be used as classes when rendering the contents of `parameters.components`. When providing a tenant repo, users must specify the tenant ID and cluster ID for which the inventory should be rendered in a value class to obtain accurate results. See a sample `cluster-info.yaml` which can be used for this purpose below. cluster-info.yaml ``````parameters: cluster: name: c-cluster-id-1234 (1) tenant: t-tenant-id-1234 (2)``````  1 Specify the cluster ID for which the inventory should be rendered 2 Specify the tenant ID. This must match the tenant ID associated with the provided tenant repo for accurate results. The command supports both YAML and JSON output. ## Inventory Lint `commodore inventory lint [PATH]...` This command provides linting for Commodore inventory classes. Currently, the command can lint component specifications and deprecated parameters. The component specification linter treats component specifications without explicit `version` field as errors. The deprecated parameter linter treats any occurrences of the reclass parameters `${customer:name}`, `${cloud:provider}`, `${cloud:region}` and `${cluster:dist}` as errors. The command takes zero or more paths to files or directories to lint as command line arguments. It silently skips files which aren’t valid YAML, as well as empty files and files containing multi-document YAML streams. All other files are assumed to be Commodore inventory classes. When linting directories, any hidden files (prefixed with a dot) are ignored. Directories are linted recursively and the same skipping logic as for individual files is applied. If no errors are found the command exits with return value 0. If any errors are found the command exits with return value 1. ## Login `commodore login` This command allows you to authenticate yourself to Lieutenant using OIDC, if OIDC integrations is enabled for your Lieutenant instance. The command will open a web-browser where you can authenticate yourself to the configured IdP. Commodore will use the returned token for future commands if no other token is explicitly provided. ## Fetch Token `commodore fetch-token` This command prints the OIDC token for the specified Lieutenant API to stdout. If necessary, the command will call `commodore login` internally to fetch a valid token for the provided API URL. ## Package New `commodore package new SLUG` This command creates a new config package repository. If not specified explicitly, the command will create the new package under `inventory/classes/` in Commodore’s working directory. The package repository is created using a Cookiecutter template which provides a skeleton for writing a new package. The command requires the argument `SLUG` to match the regular expression `^[a-z][a-z0-9-]+[a-z0-9]$`. Additionally, the command prevents users from creating packages using reserved names or prefixes.

The template also provides many meta-files in the component repository, such as the readme and changelog, standardized license, contributing and code of conduct files, a documentation template, and GitHub issue templates and actions configuration.

## Package Compile

`package compile PATH TEST_CLASS`

This command allows user to configure configuration packages standalone.

The command takes two command line arguments, the path to the package and the test class in the package to compile.

By default, the command creates a temp directory in `/tmp` which is used as the working directory for compiling the package. To keep an automatically created temp directory for subsequent compilations, users can specify `--keep-dir` to skip deleting the temp directory created by the command. Users can specify a custom temp directory location with flag `--tmp-dir`. If the path provided with `--tmp-dir` doesn’t exist, Commodore will create it as a directory.