* feat(config): add `overrideDescription` option
Presets which extend many other presets used an `ignoreDeps: []` sentinel
to keep their own one-line summary in the onboarding PR instead of one line
per extended preset. Replace that hack with an explicit `overrideDescription`
option, which is consumed and removed while presets are resolved.
The resolved descriptions are unchanged. Repositories which set
`ignoreDeps: []` in their own config no longer lose all preset descriptions
in their onboarding PR.
* fixup! feat(config): add `overrideDescription` option
* fixup! feat(config): add `overrideDescription` option
* fixup! feat(config): add `overrideDescription` option
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.
As part of future changes, we'll introduce coverage of all properties
under `packageRules`.
Before we do this, we should use `$ref`s to make sure that we don't
duplicate the definitions too much.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* feat: allow separate versioning for constraints
As noted in #31831, there are times where it can be useful to override
the version that a given datasource uses, when performing
`constraintsFiltering=strict.`
This should only be applicable to the "additional" constraints, so we
make sure to validate this.
As this is new functionality, any misconfiguration should be marked as
an error.
We can make sure to provide a real-world usecase for this (taking
inspiration from `rails`' versioning of the `rubygems` constraint).
This will be used in the future by the extraction of the `go` directive,
which requires a different versioning to the default `semver`.
* fixup! feat: allow separate versioning for constraints
* fixup! feat: allow separate versioning for constraints
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* extra-log-context
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
Instead of inline documentation with JSDoc, we can use an optional
`description` field that can be accessed programatically.
This means the `description` can also be added to our JSON Schema for a
Tool, or be the only output when a non-Tool constraint, as the
description for non-Tools are more clear than the autogenerated text.
We can make sure we continue to export the known names, as well as the
full definitions.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* docs(json-schema): add `constraints` and `installTools`
This requires `toolNames` and `additionalConstraintNames` are exported
for use.
* fixup! docs(json-schema): add `constraints` and `installTools`
Editors such as VSCode will look for `markdownDescription` to render the
description, if present, and will render that as Markdown, instead of
plain text.
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>
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>
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.
renovate[bot]