mix workspace.check (Workspace v0.2.1)

View Source

Check the workspace using the configured checks.

$ mix workspace.check

Command Line Options

  • -c, --check... (atom) - Specify a check id to be executed. If set only those checks will run. Can be set more than once. [values can be grouped with the , separator]

Filtering options

  • -e, --exclude... (string) - Ignore the given projects [values can be grouped with the , separator]
  • --exclude-tag... (string) - If set, any projects with any of the given tag(s) will be excluded. For scoped tags you should provide a colon separated string (examples: shared, scope:api, type:utils). For selecting a specific tag use --tag [values can be grouped with the , separator]
  • -p, --project... (string) - The project name, can be defined multiple times. If not set all projects are considered [values can be grouped with the , separator]
  • --tag... (string) - If set, only projects with the given tag(s) will be considered. For scoped tags you should provide a colon separated string (examples: shared, scope:api, type:utils). For excluding a specific tag use --exclude-tag [values can be grouped with the , separator]

Display options

  • --verbose (boolean) - If set enables verbose logging [default: false]

Global workspace options

  • --config-path (string) - The path to the workspace config to be used, relative to the workspace path [default: .workspace.exs]
  • --workspace-path (string) - If set it specifies the root workspace path, defaults to current directory

What to check

This depends on your codebase and your conventions. When your mono-repo grows it is becoming more tedious to keep track with all projects and ensure that the same standards apply to all projects.

For example you may wish to have common dependencies defined across all your projects, or ensure that all packages have a valid maintainer set. Checks should be used for verifying the high level conventions of your project and your business rules.

Workspace comes with some basic checks included that allow you among other to:

Check Workspace.Check for more details on checks and a guide on how to implement your custom check.

Checks config

All checks must be configured under the :checks option of your workspace config. You can use any of the officially supported checks or implement your own.

Here is an example of some checks from the workspace repo:

checks: [
  [
    id: :description_set,
    module: Workspace.Checks.ValidateProject,
    description: "all projects must have a description set",
    opts: [
      validate: fn project ->
        case project.config[:description] do
          nil -> {:error, "no :description set"}
          description when is_binary(description) -> {:ok, "description set to #{description}"}
          other -> {:error, "description must be binary, got: #{inspect(other)}"}
        end
      end
    ]
  ],
  [
    id: :deps_path,
    module: Workspace.Checks.ValidateConfigPath,
    description: "all projects must have a common dependencies path",
    opts: [
      config_attribute: :deps_path,
      expected_path: "artifacts/deps"
    ]
  ],
]

Grouping checks

Checks can be organized in groups. Groups will be used by the task for pretty printing a header followed by all relevant checks.

The :group can be set in the check definition:

checks: [
  [
    id: :description_set,
    group: :package,
    ...
  ],
  [
    id: :valid_maintainers,
    group: :package
    ...
  ]
]

Groups headers styling

By default a yellow header will be added for each group with the group name as title. If you wish you can configure the styling and/or the title of each group header through the :groups_for_checks configuration:

groups_for_checks: [
  package: [
    style: [:red]
  ],
  docs: [
    title: " 📚 Documentation checks",
    style: [:yellow_background, :white]
  ]
]

Check Workspace.Config for more details.