* 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>
* chore(tools): pre-format output JSON files
This also helps when running changes locally, as there's no need to run
`prettier` to check the actual updates between what's committed.
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
* refactor: directly use `prettier`
* fixup! refactor: directly use `prettier`
---------
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
* feat(mise): automagically support all tools through Mise Registry
As noted in #42250, we should try and auto-support tools from Mise where
possible.
Similar to other areas of the codebase, we should use the "static data"
pattern, and periodically sync the `mise registry --json` output with
`lib/data/mise-registry.json`, and then auto-detect the tools that we
support through the known backends the tools support.
This takes lower precedence than existing in-code tool definitions, so
we can still provide an "override" if we can support lookups or version
extraction more appropriately.
Because we now have many more tools we (mostly) support out-of-the-box,
we need to provide an improved documentation page, and:
- only link to tools we have an explicit tools URL for
- note where a backend may not be supported
To automate the updating of this data, we:
- make sure we have `mise` in GitHub Actions, before we run
- don't pin the `mise` version to make sure that we're always seeing the
latest supported tools
- make sure the commits generated are now `feat(...)`, as they introduce
functionality changes (in the case new tool(s) are supported)
This improves support from ~170 tool short names to just over 1000.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* refactor: use Typescript
As we can now, we should.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* refactor(tools/static-data): use Zod schemas for parsing
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* refactor(mise): use Zod for types
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* chore(mise): prefer the GitHub backend over other sources
As we generally prefer it as a project, we should automagically use that
when looking at a mise registry entry.
With help from GPT-4.1 to write the `sortBackend` function.
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
* test: ignore else coverage
* docs(mise): preference of `github` backend
* docs(mise): auto-link autogenerated tools
* perf(mise): sort registry only once
* refactor(mise): transform when parsing
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
* refactor: use `execa`
* perf(mise): read the Mise registry once
* perf(mise): pre-transform
---------
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>
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
* docs(constraints): list the possible `constraints` and `installTools`
Now we have a stronger type for what a valid tool constraint is, and
what additional constraints are, we should be very explicit with what
each option is, and specify them in the `constraints` as well as our
`installTools` docs.
* test: add coverage
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 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`
As we do with the other modules, we should include Managers too.
Although there are many, it can be a little jarring not seeing the list
of Managers when viewing a specific one.
This requires we also show the "display name" (`Ansible`) in the
sidebar, and then use the more verbose `Automated Dependency Updates for
Ansible` as the header.
To do this, we can utilise the `sidebar_label` (which was previously
used in Docusarus, but unused by Material for MkDocs) via a custom hook
to inject the label for the sidebar.
Unfortunately this requires a custom hook, which will make moving away
from Material for MkDocs (to Zensical) a little less straightforward.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
As they are configuration options and can be quite code-y we should
render them like this.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
As noted in #42798, `platform=local` and other experimental platforms
are seeing the page for each of those platforms having duplicate
content.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* docs(mise): render sorted table of short-names for tools
As a way to improve the rendering of the large list of tools that we
support for mise-en-place, we can render them as a table.
This allows us to sort them by tool name, as well as make it clearer
which source the tool is from.
As part of future changes, we'll introduce more information and sources
of the table, so rendering them as a table will be more readable.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* docs(mise): wrap tool names in code tags
As they're generally a command.
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
To provide more programmatic means to determine what environment
variables configure Renovate configuration options - and whether they're
Repo, Inherit or Global config options - we can expose these in two
forms:
- `getEnvOptionsMap()`
- a static JSON file, `renovate-env-options.ts`
This will provide programmatic use-cases from a plain JSON file that can
be used more readily - especially as it's distributed in the docs and
built package - as well as a function that can be used by users of
Renovate-as-a-library.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
renovate[bot]