Adds a custom oxlint rule renovate/v8-ignore-no-count that flags the
count form '/* v8 ignore next <N> */'. The count is not honored by
vitest's ast-v8-to-istanbul hint parser, which captures only the
keyword (if/else/next/file); 'next' always exempts exactly the next
AST node. Trailing counts therefore suggest a line range that is never
applied and mislead readers.
The rule is autofixable (drops the count, preserving actual behavior)
and has been applied to all existing occurrences.
* docs: correct `onboardingConfig` example
As we'll be enforcing this as valid Global config in future commits.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: correct `module.exports` syntax
As we'll be enforcing this as valid Global config in future commits.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: completely skip `doc-fence-check` on code blocks only used for synatx highlighting
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: skip schema validation on non-config snippets
As we'll be enforcing this as valid Global config in future commits.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* chore(tools/doc-fence-check): validate JSONC and Javascript code blocks
To further ensure that our documentation is well-formed, we can validate
that JSONC and Javascript code blocks are well-formed syntactically, and
are valid Renovate configuration.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* chore(tools/doc-fence-check): allow opting out of syntax validation
On top of schema validation wanting to be disabled, we should also
support disabling the syntax validation, in the case that we're using
`json` code blocks for syntax highlighting, but they're not necessarily
well-formed JSON.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: use `json` syntax highlighting
As `jsonc` doesn't seem to exist in Material for MkDocs.
As it's only for syntax highlighting, we need to opt out of validation.
* tsc
---------
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
As it doesn't work, as commits from `github-actions[bot]` can't be used
to trigger CI, and we don't want to use a PAT (as it'll then shows as
an author on PRs).
* docs(next-major): update links to Renovate 44 examples
After the inadvertent release of Renovate 44, we still need to follow
post-release actions, so we may as well keep these updated.
* docs(next-major): add reference to major version bump in docs
* feat(git): validate length commit shas
* test: adapt test mocks
* chore: update import paths
* feat(git): make the validation more strict and support repositories using sha256
* test: add fakeSha function for deterministic git commit shas in tests
* ci: add agent instructions and ClaudeCode hooks
* refactor: rename start-check and use schemas
* fix: remove redundant flow diagram
* refactor: add block utility
* docs: add reference to development documentation
* ci: add pretooluse hook
* test: remove unnecessary schema tests
* ci: add --all flag run fixer and linters in a single command
* ci: switch stop hook to `pnpm check --all`
* refactor: use simple git
* refactor: use zod/v4
* ci: prevent usages of pnpm vitest
* ci: add must read and code example for codeBlock
* fixup! simplegit by allowing user pagers and editors
* ci(agent hooks): run installs on worktree changes
* docs: shorten description
* chore: remove additional new line at the end
* explicitly fail if parsing fails
* fix: rename to kebabcase
* docs: reduce commands highlighted for local dev
* 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 `{ ... }`
* chore: move from volta.sh to mise
* !fixup chore: move from volta.sh to mise
* Update mise.toml
---------
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
* docs: explicitly document `depTypes` each manager supports
A long-standing question we receive is "what `depTypes` can I match
against in my project".
Although the best recommendation we usually have is "check the
`packageFiles with updates" log line (as a very key log line for users),
we can go one step further and try and create a stronger contract.
To do this, I've used Claude Sonnet 4.6 to work through the codebase,
determine areas that a `depType` is set in a manager (statically or
dynamically) and generate a structured, typed, means to document how
they're used.
Through a few iterations of the process, and attempts at human-written
documentation, we've settled on:
- prioritising autogenerated documentation (for humans to read) to note
what `depTypes` are known, and what they are
- `knownDepTypes`, to describe any known, static, `depType`s and their
human-readable meaning
- with the `prettyDepType`, if used
- `supportsDynamicDepTypesNote`, to add a Markdown note to the generated
documentation
While here, we also:
- make sure to note this in the "adding a new package manager"
documentation
- remove any hand-written references to `depTypes` in each manager's
documentation page
- correct the Gleam `depTypes`
- make sure to use the `knownDepTypes`'s `prettyDepType` definition if
we know it, for a given `depType`
The descriptions have been generated by Claude Sonnet, with some
human-written tweaks where appropriate.
[0]: https://github.com/renovatebot/renovate/discussions/15176
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fixup! docs: explicitly document `depTypes` each manager supports
* docs(manager): display `depTypes` documentation if none present
For consistency, and to make it more explicit.
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@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.
* base: pile foundation
* refactor(tools): Split check.ts into modular components
- Separate files for types, coverage, git, tui, execution, test-filter
- Fix signal handler timing (register at module load)
- Export getMatchingShards/getTestPatternsForShards from test-shards.ts
Sebastian Poxhofer