Editors such as VSCode will look for `markdownDescription` to render the
description, if present, and will render that as Markdown, instead of
plain text.
This also makes sure that our URL fragments should be more consistent
over the years, as duplicate names (across parent and child options)
cannot clash.
This also corrects links from the code to include the new fragment.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
As a follow-up from #36261, we should auto-generate this in our
documentation to keep it up-to-date.
If the `getPinnedValue` function is present, we should imply
`rangeStrategy=pin`.
Co-authored-by: Claude Sonnet 4.5 <jamie.tanna+github-copilot@mend.io>
As noted in #40608, we're currently showing an outdated list of possible
configuration filenames.
We can instead automate this by using the known configuration files we
know.
As we don't yet support the Platform-specific filenames, we shouldn't
include them, but add a TODO so we don't miss it.
As noted in #40804, `matchUpdateTypes` can either be an `UpdateType`, or
it can be a glob.
This makes sure that the schema is aware it's either an enum, or it's an
arbitrary string.
As noted in #40439, it would be useful to provide editor suggestions for
the possible values of `extends`, so a user can start their
configuration with recommended presets.
We can do this using a custom `anyOf` that includes these options as an
`enum`.
Co-authored-by: Claude Sonnet 4.5 <jamie.tanna+github-copilot@mend.io>
* docs/41127-parents-may-want-to-split-over-multiples-lines
* refactor(docs): sort parents alphabetically in table and add unit tests
* refactor(docs): table - use expect instead of assert
* refacto(docs) : remove unnecessary vitest import
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
* refactor(docs): table - rename index so there are rowIndex and colIndex
* refactor(docs): rename config.test.ts to utils.test.ts
---------
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
* refactor(platform): programatically mark Platforms as experimental
As part of future changes, we'll want to be able to more
straightforwardly determine whether a given Platform is experimental.
To do this, we can add a new optional `experimental` flag to the
`Platform`.
As part of having this available, we can refactor how our docs for
Platforms are built, and replace a hand-authored experimental notice, we
can automagically insert it into the built docs.
To make sure that we don't break the rendering of the Markdown for
Mkdocs, we need to insert the experimental notice after the page
heading.
As we're now using the Platform itself, not only the ID, we need to
refactor how `tools/docs/platforms.ts` renders the pages.
* docs(platforms): clarify which Platforms are experimental (#41249)
* chore: format code block
---------
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
As part of future changes, we need to be able to specify the start/end
of replacements in documentation, as we have multiple entries in the
same page.
We can also rename the variable so it's clearer that it's the default
value, not the current scoped value.
To surface which Managers support Lock File Maintenance more
prominently, we can note which file(s) are available for it when we
autogenerate the docs.
* feat(nuget): add supportsLockFileMaintenance flag
The NuGet manager supports lock file maintenance via `packages.lock.json`
but was missing the `supportsLockFileMaintenance` export.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* feat(manager): add lockFileNames metadata to all lock file managers
Add `lockFileNames` field to `ManagerApi` interface and export it from
all 24 managers that support lock file maintenance. This metadata will
be used to auto-generate the lock file support table in docs.
Also adds a validation test ensuring managers with
`supportsLockFileMaintenance` always provide `lockFileNames`.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* feat(docs): auto-generate lockFileMaintenance lock files table
Replace the hardcoded lock file support table in configuration-options.md
with autogenerate markers and generate it from manager metadata during
docs build. This ensures the table stays in sync with manager code
automatically.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
As noted in #38728, we want to make sure that we only have repo level
configuration in repo configuration.
This makes sure that the resulting JSON Schemas are output with only the
configuration options that are relevant.
Additionally, as a way to inform users that they are using a documented
global-only option in their repo-level configuration, we can use JSON
Schema validation rules to provide a nudge to users that they're using
incorrectly placed configuration.
This isn't currently enforced when Renovate runs, nor is the JSON Schema
used to apply validation.
However, it will surface information to the user (i.e. in folks' local
editors) and provide faster feedback of "oh, I shouldn't be using this
configuration".
With some help from GPT-4.1 to craft the `not.required`, and correct the
typing.
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
In shared preset repositories, some users will use a mix of Inherit
Config and Repo Config options with the existing JSON Schema.
As part of Renovate 43, we're removing the ability for any global
options to be usable in Repo Config, which would also mean that it's now
either a case of "ignoring warnings in my editor" and "using Global
Config JSON Schema", which isn't a great option.
We can instead create a third JSON Schema, one which is focussed on
shared presets that can include Inherit Config options.
This makes it clear that the repo config's JSON Schema should not be
used for anything Inherit Config.
Noticed while making changes in the JSON Schema generation, but we're
currently returning a mutable reference to all of our options, which
means that it might be possible to (accidentally) change configuration
options that then affects all of the running Renovate process.
To handle this, we can make sure to `Object.freeze` the options, as well
as making sure our types clarify this is read-only.
This isn't something that should be user-facing, but makes sure that
we're keeping these immutable.
We also need to make sure any modifications now return a new config
option.
When we return a default value, we need to return a clone, so it's not
the frozen default value, as that then means it can't be modified (i.e.
in tests).
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
As part of future changes to introduce further typings for Commander
(#40546), we need to provide stronger types as the `version` will now be
typed.
We can erase the `SemVer` type, and pass around a `string`, instead as
it's not necessary to keep.
We're currently always skipping the detection of open bugs/features, so
even though [0] introduced authentication to GitHub, this didn't
actually lead to the lookup when running in CI.
If we're not running in Renovate's CI build (i.e. as part of the release
process) or the docs site's CI build (as part of post-release
operations) we should continue to skip the build, when running in CI.
This also makes it clearer with a WARN log line to explain why this is
being skipped.
This is a re-apply of ae46c57f56, as well
as making sure that the `GITHUB_TOKEN` is explicitly passed as
`extraEnv`, otherwise we see i.e.
```
ERROR: Error getting query results
"err": {
"cmd": "/bin/sh -c gh issue list --json \"title,number,url,labels\" --search \"type:Bug\" --limit 1000",
"stderr": "gh: To use GitHub CLI in automation, set the GH_TOKEN environment variable.\n",
"stdout": "",
"options": {
"encoding": "utf-8",
"env": ["CI", "HOME", "PATH", "LANG"],
"maxBuffer": 10485760,
"timeout": 900000
},
"exitCode": 4,
"name": "ExecError",
"message": "Command failed: gh issue list ...\ngh: To use GitHub CLI in automation, set the GH_TOKEN environment variable.\n",
"stack": "ExecError: Command failed: gh issue list ...\ngh: To use GitHub CLI in automation, set the GH_TOKEN environment variable.\n\n at ..."
}
```
As we can see, the `env` isn't automagically picking up the
`GITHUB_TOKEN`, so we should explicitly pass it.
[0]: https://github.com/renovatebot/renovatebot.github.io/pull/746
* Revert "fix(docs): wire in `GH_TOKEN` for `gh` CLI (#39812)"
This reverts commit 295eaac4d0.
* Revert "fix(docs): add required permissions for `build:docs` (#39809)"
This reverts commit bbd30ce930.
* Revert "fix(docs): look up open issues on `main` builds for Renovate docs (#39801)"
This reverts commit ae46c57f56.
We're currently always skipping the detection of open bugs/features, so
even though [0] introduced authentication to GitHub, this didn't
actually lead to the lookup when running in CI.
If we're not running in Renovate's CI build (i.e. as part of the release
process) or the docs site's CI build (as part of post-release
operations) we should continue to skip the build, when running in CI.
This also makes it clearer with a WARN log line to explain why this is
being skipped.
[0]: https://github.com/renovatebot/renovatebot.github.io/pull/746
With `allowedValues`, we will almost always have multiple values. To
render them better, we can render this array as the JSON stringified
alternative, which reads a little better.
This requires we make sure that the array isn't pre-stringified, which
would JSON stringify as i.e. `"auto, enabled"`.
Now we have a global schema for self-hosting configuration, we can
deprecate the use of global configuration in a repository configuration.
Unfortunately the JSON Schema version we use does not provide native
deprecation functionality, so we can prepend the deprecation notice to
the `description`.
Then, as part of #38728, we will remove this in the next major version
of Renovate.
Closes#38729.
As noted in #38727, it would be convenient to distribute a separate JSON
Schema that is explicitly for "global" / "admin" / "self-hosted"
configuration, separate to the repository configuration in our current
`renovate-schema.json`.
This gets wired in as an additional JSON file, and will have a different
set of configuration options in the future, noted by the `isGlobal`.
Closes#38727.
So we can, in the future, modify other configuration more easily.
We should also rename `configurationOptions` to clarify they're Renovate
configuration, not options for this function.
As noted in #38749, we need to upgrade to draft-07 of JSON Schema to
upgrade our dependency on AJV.
To do so, we "just" need to update the `$schema`, as we're not using
anything that's been deprecated/removed/changed as part of draft-07.
This doesn't impact anything user-facing, and the schema doesn't change.
This appears to be supported by `vscode-json-languageservice`, which is
used by several IDEs (including VSCode) and editors to perform JSON
Schema validation in-editor.
Note that if we don't update `schemaId` to `auto`, we end up with errors
such as:
Error: no schema with key or ref "http://json-schema.org/draft-07/schema#"
Closes#38749.
fix(tools/json-schema): correctly set version in generated JSON Schema
In #38567 we tried to wire in the version of Renovate into the generated
JSON Schema. This unfortunately didn't work, as we don't have the
release number known at the time we're currently calling the JSON Schema
generation.
To fix this, we can make sure that at the point we're generating the
JSON Schema as part of the release process, we can wire in the version
as part of `generateSchema`.
In #38567 we tried to wire in the version of Renovate into the generated
JSON Schema. This unfortunately didn't work, as we don't have the
release number known at the time we're currently calling the JSON Schema
generation.
To fix this, we need to pass in the version as part of `generateSchema`.
However, to do so, we'd need to make the `schema.title` and
`schema.x-renovate-version` no longer constants that derive the version
from the `package.json`.
As a prefactor, we can refactor this into the `generateSchema` function,
instead of being file-level (constant) variables, and make sure we pass
around the `options` and `properties` variables, too.
Per #37994 we don't currently provide any historical copies of JSON
Schema documents for Renovate's repo configuration file format.
It would therefore be useful to provide this metadata to users, both in
the `title`, but also as an extra field that can be relied upon.
Jamie Tanna