With the new hardening on blocking internal hosts with outbound HTTP
calls, we should build on top of this to ensure that the UX is better
when a preset is blocked.
We can do this by making sure that when `HOST_BLOCKED`, we report a more
targeted config validation error.
We can also make sure to pass around our `internalGrants`, similar to
how we currently allow an admin's `headers` are handled.
Co-authored-by: Claude Fable 5 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
* test(core): replace file snapshots with explicit assertions
* test(core): replace inline snapshots with explicit assertions
* test(core): assert on relevant sections instead of full bodies
* test(core): drop assertions implied by full equality
* test(core): address review feedback
* test(core): use resolves instead of awaiting inside expect
* feat(presets): add @oxlint/* packages to packages:linters
Groups oxlint plugin packages together with oxlint itself.
* feat(presets): add @oxlint/plugins to monorepo:oxlint
* test(presets): update linters snapshots for @oxlint/**
* feat(manager/github-actions): add `workflow` depType for reusable workflow calls
A job-level `uses:` pointing at `owner/repo/.github/workflows/<file>.yml@<ref>`
calls a reusable workflow rather than running an action, but both got the
`action` depType, so `matchDepTypes` could not tell them apart.
Give a reference whose sub-path is exactly `.github/workflows/<file>.yml|.yaml`
the new `workflow` depType. Every other sub-path, such as
`github/codeql-action/init`, stays an action.
The existing depType-keyed sites now accept both values, so nothing else
changes behaviour: the `actions.lock` file records reusable workflow calls too,
and `helpers:pinGitHubActionDigests` pinned them before this split.
* Apply suggestions from code review
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
* 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
* feat(presets): support relative `extends` references inside presets
Presets which are fetched from a repository can now reference sibling
presets relatively, instead of repeating their own source, repository and
tag:
- `./x` resolves against the directory of the preset file with the
reference
- `../x` resolves against the parent directory of that file
- `/x` resolves against the root of the preset repository
The source, repository and tag of the preset which holds the reference are
inherited, so `./system/registries` inside `github>org/repo#v2.0.0`
resolves to `github>org/repo//system/registries#v2.0.0`. A reference which
resolves to the `default` preset at the repository root is emitted in the
plain repository form, so `github>org/repo#v2.0.0`, which keeps it
deduplicated against the way consumers spell the very same preset.
A reference must stay inside its repository, its final path segment must
name a preset file rather than a directory, and it can carry parameters
but neither its own `#tag` nor a `:subPreset`. Parameters may contain a
Handlebars template, including a sub-expression such as
`./group({{ lower (env.TEAM) }})`, while a templated path cannot be
resolved and is left alone. A reference must also not carry a source
prefix, so strings such as `local>./x` or `github>../x` are rejected as
invalid.
References are canonicalized lazily, while the preset which holds them is
fetched in `getPreset()`, after migration and massaging. Only presets from
a repository hosted source, so `github`, `gitlab`, `gitea`, `forgejo` and
`local`, are walked. A relative reference which has no parent preset, for
example in a repository config, an inherited config or in `globalExtends`,
is reported as a validation error for that entry.
Relative entries of a preset's `ignorePresets` are resolved in the same
way, so a preset can neutralize a preset which it references relatively,
as long as the consuming repository does not set `ignorePresets` itself.
A reference which cannot be resolved is kept raw and logged, which lets
consumers neutralize it with `ignorePresets`, and it only fails per entry.
Because relative references cannot be resolved while a config is
validated, they are stripped from a `packageRules` entry before its
presets are resolved. A rule which is then left without any selector is
reported as a warning rather than as an error, since the stripped preset
may still provide the missing selectors. Rules without relative references
keep failing hard as before.
The `renovate-config` manager reports relative and unparsable `extends`
entries with a skipReason, instead of dropping them, and ignores templated
entries which can only be resolved at runtime.
Behavior change: an `extends` string which starts with `./`, `../` or `/`,
such as `./x`, `../x` or `/x`, is now read as a relative reference. Before
it was parsed as a local repository name, which in rare cases could
accidentally resolve through the dot segment normalization of the request
URL. For the same reason a source prefixed relative looking string, such
as `local>/org/repo`, `github>./x` or `npm>./x`, is now rejected as an
invalid preset.
* fix(presets): parse scoped npm presets with explicit `npm>` prefix
`npm>@scope/name` was parsed as a local preset, because the heuristic for
local presets matched before the `npm>` prefix was stripped.
Every other use of `npm>` keeps its current behavior, so `npm>foo` still
falls back to the npm package `renovate-config-foo`, `npm>owner/repo` is
still resolved as a local preset and nested prefixes such as
`local>npm>foo` keep working.
* refactor: remove duplicated preset source
* docs: streamline new docs
* add more docs for skipReason and add requested changes
* Apply suggestions from code review
Co-authored-by: Jamie Tanna <github@jamietanna.co.uk>
* test(presets): drop object literal type casts in relative preset spec
---------
Co-authored-by: Jamie Tanna <github@jamietanna.co.uk>
Add distinct hints to the multi-snapshot tests flagged by the rule
and regenerate the affected snapshot files, then re-enable the rule.
Part of #43845
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* feat(presets): link to Octochangelog for updates to Renovate itself
Related to #41809, and a recommendation I personally have for folks
updating their version of Renovate via Renovate, we can use
Octochangelog to provide a nicer breakdown of Renovate CLI release
notes, grouping them by headers i.e. "Features" and "Bug Fixes" across
all version(s) being updated.
This overrides the default link i.e.
```
https://app.renovatebot.com/package-diff?name=renovate&from=43.198.0&to=43.206.1
```
to:
```
https://octochangelog.com/compare?repo=renovatebot%2Frenovate&from=43.198.0&to=43.206.1
```
As this is a strong recommendation, we add it into `config:recommended`.
* fixup! feat(presets): link to Octochangelog for updates to Renovate itself
As noted in #15827, it would be useful to log the "shallow"
configuration for a given repository - that is, the resolved
configuration, but without any Renovate internal presets being included.
This will be very useful for debugging, as it shows the final resulting
configuration, but without the - often very - verbose internal presets.
In the case that only this log line is shared, we can make sure to
reference the version of the Renovate CLI in the log line.
This requires building on top of changes in
6a4fa3f245 to be able to return a `merged`
and `unmerged` list of presets, and uses helpers from
c8f42e86b4, and
66b84dd12b to process the internal presets
accordingly.
Since we first worked on this, we've worked on improvements to caching
which should provide a require no additional performance overhead
performing this resolution twice.
This can also lead to being able to understand more clearly how Renovate
configuration is being used[0], as we have the final resolved configuration.
We want to make sure we don't try and merge or visit any internal
presets if we're not going to merge them, so we can avoid verbose
`config` or `visitedPresets` results.
[0]: https://www.jvt.me/posts/2024/04/14/renovate-config-sql/
As part of future changes, we want to log the shallow configuration (the
full resolved configuration, but without any internal Renovate
configuration presets), where we'll want to note which presets have not
been merged in.
Before that, we can start with an initial refactor to indicate which
have been merged, and return them.
When working with Go modules, the `golang.org/x` need to be treated
slightly differently, as they're hosted on Google's
`cs.opensource.google` infrastructure.
This adapts changes from [0] to:
- provide a linked `depName`, through to `pkg.go.dev` for the package
- provide a link through to `cs.opensource.google` for the given
changelog
We also wire this in by default for `config:recommended` users.
[0]: https://code.forgejo.org/forgejo/renovate-config/src/commit/42f4672021ac9907141d34966f38f735be401734/go.json#L59-L73
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
To reverse this change, you can add ``"ignorePresets": ["mergeConfidence:age-confidence-badges"]`` to your global or shared config.
BREAKING CHANGE: Merge Confidence badges will now be included by default with the `config:recommended` preset.
Jamie Tanna