Skip to main content
Pro and Enterprise plans include CI checks for GitHub repositories.
Use CI checks to lint your docs for errors and provide warnings before you deploy. Mintlify CI checks run on pull requests against a configured deployment branch.

​
Installation

To begin, follow the steps on the GitHub page.

​
Configuration

Configure the CI checks enabled for a deployment by navigating to the Add-ons page of your dashboard. Enable the checks that you want to run. When enabling checks, you can choose to run them at a Warning or Blocking level.
  • A Warning level check never provides a failure status, even if there is an error or suggestions.
  • A Blocking level check provides a failure status if there is an error or suggestions.

​
Available CI checks

The broken link CI check works like the CLI link checker. It automatically searches your documentation for broken internal links between pages within your site. It does not check external links to other websites. To see detailed results for broken links on a pull request, click the Checks tab, then click the Mintlify broken links check. The results list any files with broken links found in the pull request.

​
Vale

Vale is an open source rule-based prose linter which supports a range of document types, including Markdown and MDX. Use Vale to check for consistency of style and tone in your documentation. Mintlify supports automatically running Vale in a CI check and displaying the results as a check status.

​
Configuration

If you have a .vale.ini file in the root content directory of your deployment, the Vale CI check uses that configuration file and any configuration files in your specified StylesPath. If you don’t have a Vale config file, the default configuration automatically loads.
The default configuration runs in Mintlify’s build environment, where StylesPath = /app/styles points to an internal directory. If you create your own .vale.ini file, use a relative path within your repository, such as StylesPath = styles.For security reasons, you cannot use absolute paths or paths containing .. in your configuration files.
Default vale.ini configuration
The default Vale vocabulary includes the following words.
Default Vale vocabulary
To add your own vocabulary for the default configuration, create a styles/config/vocabularies/Mintlify directory with accept.txt and reject.txt files.
  • accept.txt: Words that the Vale linter should ignore. For example, product names or uncommon terms.
  • reject.txt: Words that the Vale linter should flag as errors. For example, jargon or words that are not appropriate for the tone of your documentation.
Example Vale file structure
Example monorepo Vale file structure

​
Packages

Vale supports a range of packages that check for spelling and style errors. Any packages you include in your repository under the correct StylesPath automatically install and run with your Vale configuration. For packages not included in your repository, you can specify any packages from the Vale package registry, and they’re automatically downloaded and used in your Vale configuration.
For security reasons, you cannot automatically download packages that aren’t from the Vale package registry.

​
Vale with MDX

MDX native support requires Vale 3.10.0 or later. Check your Vale version with vale --version.
To use Vale’s in-document comments in MDX files, use MDX-style comments {/* ... */}:
Vale automatically recognizes and respects these comments in MDX files without additional configuration. Use comments to skip lines or sections that you want the linter to ignore.
Do not place {/* vale off */} or similar MDX expression comments as direct children of a JSX component between sibling elements. For example, between two <Step> elements inside a <Steps> component.Place comments inside a specific element’s content or restructure the content to avoid needing comments.