Jamie Tanna
128f446e08
* 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 `{ ... }`
1.4 KiB
Docs site
The Renovate docs site is built from this repository.
The publishing process is triggered automatically on commits to main.
If you have submitted a documentation PR and your changes are not published within a day feel free to ping the maintainers, on the PR that introduced the docs change.
Fenced code blocks
JSON code blocks will be validated to ensure that they are:
- well-formed JSON
- Renovate config which does not need config migration
- valid Renovate configuration (with no warnings or errors)
This is validated through pnpm run doc-fence-check.
It is possible to completely ignore this validation check by using a <!-- schema-validation-disable-next-block --> comment before the code block.
Where a JSON code block is not Renovate config, you can specify:
```json {configType=none}
{
"in": "valid"
}
```
By default, the validation treats a JSON code block as Repository Config. When writing a JSON snippet for Global Self-Hosted config, you will need to note that:
```json {configType=global}
{
"allowedEnv": ["foo"]
}
```
It may be the case that there is a configuration warning that appears which may be safe to ignore, which can be done so with:
```json {ignoreConfigWarnings=true}
{
"example-deprecated": true
}
```