Skip to main content

Validation Checks

Validation Checks

Recommended

Understand every validation step performed before Custy workflows begin.

Commandcusty validate

Category

Validation

Quick Command

custy validate
validationworkflowgitconfiguration

Overview​

The validate command performs a sequence of independent validation checks.

Each check verifies a specific prerequisite required by later Custy workflows.

If a validation step fails, execution stops immediately and Custy reports both the reason for the failure and a suggested action for resolving it.

Validation Categories

What Custy Checks

Git Repository

Verify that the current directory is a valid Git repository before continuing.

Repository Configuration

Verify that required repository configuration such as configured remotes and version files exists.

Project Resources

Confirm that required template files and supporting resources are available.

Repository State

Verify that the repository is in a suitable state for commit-related workflows.

Validation Sequence

Custy performs validation in the following order.

StepValidation
1Git repository
2Git remote
3Version file
4Commit message template
5Tag message template
6Staged changes
7Commit validation provider preflight
8Commit message template availability
9Tag message template availability

This sequence ensures that inexpensive environment checks are completed before workflow-specific validation begins.

Repository Validation

Git Repository​

Custy first verifies that the current directory belongs to a Git repository.

If the directory has not been initialized with Git, validation stops because subsequent workflow commands depend on Git operations.

Git Remote​

Custy verifies that the configured remote exists.

The remote name is obtained from your project configuration rather than being hard-coded.

This allows projects to use names such as:

  • origin
  • upstream
  • backup
  • another custom remote

depending on the project's configuration.

Project Resource Validation

Version File​

Custy verifies that the configured version file exists.

The exact file location depends on your project's configuration.

Typical examples include:

  • __version__.py
  • another project-specific version file

Commit Message Template​

Custy verifies that the configured commit message template exists.

This template is typically generated by running:

custy init

or

custy init --mode templates

Tag Message Template​

Custy also verifies the configured tag message template before workflows that require annotated tags or generated tag messages.

Repository State Validation

Staged Changes​

Before commit-oriented workflows begin, Custy verifies that files have already been staged.

Depending on the selected options and project configuration, Custy may:

  • accept existing staged files,
  • automatically stage modified files,
  • allow empty staging when explicitly requested,
  • or stop validation and explain how to resolve the problem.

This validation helps prevent accidental empty commits.

Commit Validation Provider

Custy resolves tool.custy.commit.validation independently from the selected version strategy. Auto mode uses Custy's validator unless both Commitizen configuration and cz are available. Explicit or strict Commitizen mode fails early when the integration is missing or invalid. Final message validation runs after the editor step in commit-producing profiles.

See the provider behavior matrix.

Relationship to Workflows

Running

custy validate

performs these checks directly.

Running

custy run

also performs the same validation stage automatically before continuing with the remaining workflow pipeline.

In most day-to-day development, users who primarily use workflow commands do not need to execute validation separately.