In the case of a config option that has both `allowedValues` and is
templateable - such as `bumpVersions.bumpType` - we should relax the
generated JSON schema to not restrict the exact value.
* docs: skip validation on JSON files that aren't Renovate config
As part of future changes, we'll enable validation on all JSON code
snippets to run Config Validation.
Before we do that, we should opt-out JSON snippets that aren't anything
related to Renovate config.
* docs: don't validate invalid Renovate config
As it's intentionally referencing a manager that doesn't exist.
* docs: don't validate partial Renovate config
As part of future changes, we'll enable validation on all JSON code
snippets to run Config Validation.
There are several code snippets we have that are part of a Renovate JSON,
but it doesn't make sense to convert these to a fully passing config, as
it'd reduce clarity on what we're trying to explain.
* docs: convert `baseBranchPatterns` snippets to code blocks
So we can validate them.
* docs: make sure that `datasourceTemplate` is set
So this passes validation.
* docs: clarify that `force` is global config
As it may not be clear, so we can make it extra clear with a `.js` file,
and note that it's global self-hosted config.
* docs: make sure `packageRules` is an array
* docs: `matchBaseBranches` needs `baseBranchPatterns` to be set
* docs: correct typo for `prBodyColumns`
* docs: mark global config snippets as such
As part of future changes, we'll use this to detect whether it's global
self-hosted configuration.
* docs: make sure `packageRules` wraps its children
* docs: add `allowedHeaders`
* docs: ignore deprecation warnings
As part of future changes, we'll use this to note that we don't care
about the validation warnings.
* docs: make sure `customManagers` wraps its children
* docs: make sure `fleet` wraps its children
* docs: validate JSON snippets are valid Renovate config
To make sure that we're always presenting valid JSON configuration to
our users, we can validate them as part of `check-fenced-code`.
As well as configuration errors we can warn for warnings, but allow code
blocks to opt-out, for instance when there's a known deprecation
affecting the code block.
We need to make sure to set `allowedEnv` for various code snippets that
reference environment variables.
* docs(development): document fenced code block checks
* docs: wrap `configType` and `ignoreConfigWarnings` in `{ ... }`
As otherwise we see build failures i.e.
WARNING - Doc file 'modules/platform/gitlab/index.md' contains a link
'../../../self-hosted-configuration.md#autodiscoverrepoorder', but the doc
'self-hosted-configuration.md' does not contain an anchor '#autodiscoverrepoorder'.
This needs to be wrapped alongside all other options like `title`.
* fixup! docs: wrap `configType` and `ignoreConfigWarnings` in `{ ... }`
As part of recent work around environment variable handling, it's clear
we should provide more user-facing documentation on how environment
variables are handled, and which are passed to child processes by
default.
We can create a "deep dive" page for this, with an autogenerated list of
the environment variables in `basicEnvVars` that are always passed to
child processes, if they're set.
We can also point self-hosted administrators and users alike to the
options they have to control this, too.
With help from GPT-4.1 for case-insensitive sorting.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
* docs(config): don't trim newline after generated config filenames
Otherwise there's no newline before the next sentence.
* docs(config): correct usage of JSON5 presets
* docs(config): rewrite overview section
- introduce a linkable section for "what filenames are supported"
- correct the usage of "config help" discussions
- keep precedence/ordering in a single paragraph
* fixup! docs(config): rewrite overview section
* ci: add local mkdocs-admonitions plugin for prettier to allow admonition preservation
* docs: remove uses of `prettier-ignore` for admonitions
* test: rather use await expect
* chore: use named group exclusively
* docs: ensure 2 spaces used for generated admonitions
As a follow-up to 4b0146ab7b and
1844916259b6dc17f532e491eb93f6116327c324., this correctly renders
admonitions with 2 spaces (1 indent).
* fixup! docs: use 2-space indentation for Markdown (#43537)
Plus using 3-space for mixed-style `<ul>` and `<ol>`s.
* fixup! docs: use 2-space indentation for Markdown (#43537)
As otherwise it breaks the rendering of the table.
As noted in #39090, MkDocs requires 4 spaces for indentation (in
particular, for nested lists) whereas our Prettier/markdownlint
configuration expects 2 spaces.
This means that when trying to use i.e. nested lists, we need to ignore
prettier and markdownlint, otherwise it fails.
To handle this, we can add a Markdown hook to override the indentation
level to 2 spaces.
This also requires we update:
- admonitions
- indented text in `index.md`
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* docs: add "previously known as" to renamed options
To provide a more searchable set of docs in the case that we migrate a
config option, we can introduce a `previouslyKnownAs` field in the
resulting generated documentation.
This allows someone to search for the previous name and find the new
option name.
For now we'll also not implement `RENOVATE_X_` variables.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fixup! docs: add "previously known as" to renamed options
This is a more involved change, which requires we handle the custom
coersion for `RENOVATE_REPOSITORY_CACHE_FORCE_LOCAL`.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
Instead of having a warning around "this is experimental" after
scrolling down to the end of the config option's description, we can
instead make it more prominent and move them all to the top - after the
table listing - but before the main body.
As noted in #40757, when using `tools/mkdocs.ts serve`, any changes to
source files require a full restart of the command, which can be
awkward.
We can add a live reload by watching for file changes in `docs/` and
retriggering the `mkdocs` process.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
At some point in the past, mise's support for the short name `kafka` was
removed.
We can warn our users that this is no longer supported, but keep our
custom logic for it, in case it returns in the future.
As a way of indicating how fresh our list of supported tools in the
registry is, we can make sure we populate the version into a note above
the table.
We can extract a type to make it easier to reference the parsed JSON
file.
This requires a small tweak to handle `content`'s table insertion.
Jamie Tanna