CodeCollection Configuration

CodeCollection Discovery

The workspace builder component of RunWhen Local scans public git repositories to match the available automation with the resources it discovers in your cluster or cloud provider.

Each individual git repository is considered a CodeCollection, which contains one or more CodeBundle(s). Each CodeBundle folder contains :

SLI or Automation Task code
Generation Rules
Templates

See the Authors documentation for more details on CodeBundle structure.

Default CodeCollection Discovery

By default, the workspace builder scans for code bundles from a built-in/preconfigured list of standard RunWhen CodeCollections. Currently, this list is:

CodeCollection	Branch
https://github.com/runwhen-contrib/rw-public-codecollection.git	main
https://github.com/runwhen-contrib/rw-cli-codecollection.git	main
https://github.com/runwhen-contrib/rw-workspace-utils.git	main
https://github.com/runwhen-contrib/azure-c7n-codecollection.git	main
https://github.com/runwhen-contrib/aws-c7n-codecollection.git	main

Changing the CodeCollection Discovery Configuration

You may want to override the default for a number of reasons:

supplementing the built-in CodeCollections with other third-party CodeCollections
suppressing one or more of the built-in CodeCollections
overriding the branch used for one or more CodeCollections
specifying a subset of the code bundles to enable for a CodeCollection

To support these use cases the CodeCollection list can be customized with a codeCollections block. This is a list of the CodeCollections to enable. A CodeCollection item in the list can be specified with either a simple string or a CodeCollection object/block with info about the target CodeCollection.

For the string specification the string is just the URL of the git repo. The string can also be the special "defaults" value, which enables all the built-in CodeCollections. This is useful if you want to enable most of the built-in CodeCollections, but suppress/blacklist some of them. If you prefix the git URL with a "!" character, then that means to exclude that CodeCollection rather than enable it. When using the string format for a CodeCollection entry the "main" branch is used. If you want to specify a different branch you need to use the object/block format.

The object block format for a CodeCollection entry is an object/dictionary with the following fields:

Field Name	Description
repoURL	URL of the git repo for the CodeCollection
branch	branch to use in the repo
tag	tag to use in the repo
ref	git ref to use in the repo
authUser	user id to use when cloning the repo
authToken	auth token credential to use when cloning repo
action	inclusion action, either `include` or `exclude`, defaults to `include`
codeBundles	List of code bundles to enable for the CodeCollection

Only one of the branch, tag or ref fields should be specified.

The authUser and authToken fields are only necessary for non-public repos. All the RunWhen-provided CodeCollections are open source, so they don't require any credentials.

The action field lets you toggle between inclusion/whitelist and exclusion/blacklist. The most common use case will just be an explicit whitelist of included CodeCollections. Since the action field defaults to include you can just omit it for that use case.

The codeBundles field is just a list of the names of the code bundles to enable. The codeBundle name is the directory name of the CodeBundle in the codebundles directory in the CodeCollection. This field is optional. If it's omitted, then all code bundles are enabled. The code bundle value can be a file glob expression like you can use is the command line shell, so you can have wildcard expressions that match multiple code bundles.

The custom CodeCollection configuration is useful for CodeCollection authors. For new third-party CodeCollections you can just add the new CodeCollection to the list. If you're developing/testing a single code bundle, you can limit the workspace builder to just that code bundle:

CODE

codeCollections:
- repoURL: https://github.com/author-account/my-custom-code-collection.git
  codeBundles:
  - my-code-bundle

If you're developing new code bundles for one of the standard RunWhen CodeCollections, then the easiest way to handle that is to fork the RunWhen repo and then stage your new code bundle code in the fork. Remember that you need to commit any changes you make to your local clone and push to the GitHub repo to make the new code accessible to the workspace builder.

CodeCollection Version Management

While the default configuration is to leverage CodeCollections from the main branches, this is mostly useful for initial setup, proof of concept, or pilot installations - in which your environment can automatically receive new CodeBundle updates in an automated manner. For production implementations, CodeCollection updates may want to be applied in a controlled manner. In this case, git tags are used to specify the CodeCollection versions that are applied to your workspace.

For example, to specify a tag and only include a few CodeCollections, the configuration may look like this:

CODE

codeCollections:
- repoURL: https://github.com/runwhen-contrib/rw-public-codecollection.git
  tag: v0.0.17
- repoURL: https://github.com/runwhen-contrib/rw-cli-codecollection.git
  tag: v0.0.24
- repoURL: https://github.com/runwhen-contrib/rw-workspace-utils.git
  tag: v0.0.3
- repoURL: https://github.com/runwhen-contrib/rw-generic-codecollection.git
  tag: v0.0.1