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 `{ ... }`
3.2 KiB
title
| title |
|---|
| Managers |
Managers
Renovate is based around the concept of "package managers", or "managers" for short. These range from traditional package managers like npm, Bundler and Composer through to less traditional concepts like CircleCI or Travis config files.
The goal of Renovate is to detect and maintain all third-party dependencies in your repositories, through the use of managers.
Supported Managers
Configuring Managers
File Matching
Most Renovate managers have a default managerFilePatterns array.
The managerFilePatterns array can hold a regular expression or glob pattern, that match against the repository file list.
Managers with no default managerFilePatterns
Some managers have no default managerFilePatterns, because they have no filename convention that would let Renovate intelligently filter them.
If there is no default filePattern, the manager is disabled.
For the manager to work, you must create a managerFilePatterns regular expression, or glob pattern.
For example:
{
"kubernetes": {
"managerFilePatterns": ["/^config/.*\\.yaml$/"]
}
}
Extending a manager's default managerFilePatterns
If the default managerFilePatterns for a manager does not match your file(s), you can extend the pattern.
You extend the pattern by configuring the manager's managerFilePatterns.
For example:
{
"dockerfile": {
"managerFilePatterns": ["does-not-look-like-a-docker-file"]
}
}
Ignoring files that match the default managerFilePatterns
Renovate will extend the existing managerFilePatterns, meaning you don't need to include the default patterns like Dockerfile in your own array.
In other words, the patterns are "additive".
If a manager matches a file that you don't want it to, ignore it using the ignorePaths configuration option.
Also, if you ever find that Renovate is not matching a file name that you're certain it should, check your preset config isn't the cause of it.
The config:recommended preset ignores common test and example directory names, for example.
Enabling and disabling managers
Enabling experimental managers
Most managers are enabled by default.
For those that aren't, typically because they are considered experimental, you can opt-in manually.
If there was a manager called some-new-manager you would enable it like this:
{
"some-new-manager": {
"enabled": true
}
}
Disabling managers
{
"gradle": {
"enabled": false
}
}
Please check the list of supported managers.
Limiting enabled managers
Say you only want to use Renovate for JavaScript packages, and to update your Dockerfile, and don't want any other updates.
You can use the enabledManagers array, to list the managers you want to use (npm, dockerfile):
{
"enabledManagers": ["npm", "dockerfile"]
}
Using the enabledManagers array disables all other managers, this includes Bundler, Composer, Docker Compose, etc.