Omnix Configuration

You can configure Omnix’s behaviour on your repository by creating a top-level om.yaml file. If there is no om.yaml file, Omnix will evaluate the flake’s .#om output instead. Prefer creating a om.yaml in general, as it is faster to read than evaluating complex Nix flakes.

Note

For am example om.yaml, see that of omnix itself

Links to this page
  • om init

    Omnix templates can be defined by adding a om.template flake output configuration. This should be an attrset of templates. The value should contain the keys template (referring to original flake template) as well as params, defined as follows:

    The configuration can also include a tests key that defines a list of tests to run on the template. Each test is an attrset with params and asserts keys that indicates the parameter values to test along with the path existance assertions. For example:

  • om health

    To add project specific health checks or configure health checks, add the following to your om.yaml:

    To see all available configuration options, run om health --dump-schema. This will dump the schema of the configuration in JSON format. Convert that to YAML to see what can be added under the om.health.default key of your om.yaml.

  • om develop

    The welcome text can be configured in your om.yaml file. For example:

    You should also create a om.yaml file in your project to avoid Nix evaluation:

  • om ci

    By default, om ci will build the top-level flake, but you can tell it to build sub-flakes (here, ./dir1 and ./dir2) by adding the following to your Om configuration:

    [!NOTE] This currently requires an explicit CI configuration in your flake, setting om.ci.default.root.dir to ..

  • Omnix
    Omnix Configuration - Configuration