* 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>
To prevent potential SSRF attempts, we can ignore a
misconfigured/malicious `next` link, and log a warning.
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
To prevent potential SSRF attempts, we can ignore a
misconfigured/malicious `next` link, and log a warning.
For self-hosted users, we can provide an experimental override if they
need to opt back in.
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
As these have been out-of-sync with what is and is not currently
supported per our documentation.
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
As per #44820, `pinDigest` updates currently don't get
`minimumReleaseAge` checks applied to them.
We can extend the recent support for `digest`s being handled by also
introducing support for `pinDigest`s to receive `minimumReleaseAge`
enforcement.
This will:
- enforce `minimumReleaseAge` on all updates that `pinDigest`s has
pending
- consider the newest resolved version's timestamp, ignoring
`rangeStrategy`-related logic
- allow unversioned releases like `latest` to /not/ be bound by
`minimumReleaseAge`, as they'll potentially not have a release
timestamp and will be unpinned forever, which is less safe (and
reduces reproducibility)
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
In some cases, we hadn't correctly wired in the `minimumReleaseAge`
checks for `digest`, due to the `currentValue` not changing.
To handle this, we need to:
- use our helper methods for calculating whether the `minimumReleaseAge`
has passed
- handle a new digest's new `releaseTimestamp`
the current timestamp
- intentionally not gate `minimumConfidence`, as this is only computed
per-release, not at the digest level
- note the fixed behaviour, and clarify when it will/will not work
- add coverage for all generated updates for `digest`s, including when
remapping a Go Modules update as a `digest`
- clarify that `filterInternalChecks` and
`applyMinimumReleaseAgeToDigestUpdate` should stay in sync
Co-authored-by: Claude Fable 5 <jamie.tanna+claude-code@mend.io>
* chore(config): be explicit about `Renovate CLI` in `prFooter`
This was something I should have done in
72968d3726.
* fixup! chore(config): be explicit about `Renovate CLI` in `prFooter`
* feat(managers/pep621): update pixi.lock if present
* test(managers/pep621): cover pixi requires-pixi from workspace table
* refactor(manager/pixi): extract shared pixi.lock update helper
* test(manager/pep621): use arrange-act-assert spacing in pixi tests
* refactor(manager/pixi): revert shared pixi.lock helper extraction
Move the extraction of the shared pixi.lock update helper into a
follow-up PR, as requested in review. The pep621 pixi processor and the
pixi manager again carry their own lock-update logic.
This reverts commit 743db204f2.
* feat(manager/pep621): gate pixi.lock updates behind allowedUnsafeExecutions
`pixi lock` can execute arbitrary code from conda package hooks, so the
pep621 manager now only updates `pixi.lock` when `pixi` is included in the
global `allowedUnsafeExecutions` option, following the same pattern as the
`mise` manager. When `pixi` is not allowed, PEP 621 dependencies in
`pyproject.toml` are still updated but `pixi.lock` is left unchanged.
https://pixi.prefix.dev/latest/security/#4-treat-package-hooks-as-code-execution
* feat(manager/pixi)!: gate pixi.lock updates behind allowedUnsafeExecutions
The pixi manager runs `pixi lock`, which can execute arbitrary code from
conda package hooks. Like the pep621 manager, it now only updates
`pixi.lock` when `pixi` is included in the global `allowedUnsafeExecutions`
option. When it is not allowed, the package file is still updated but
`pixi.lock` is left unchanged.
https://pixi.prefix.dev/latest/security/#4-treat-package-hooks-as-code-execution
BREAKING CHANGE: The `pixi` manager no longer updates `pixi.lock`
automatically. To keep `pixi.lock` updated, add `pixi` to the global
`allowedUnsafeExecutions` option.
feat(manager/pixi): gate pixi.lock updates behind allowedUnsafeExecutions
The pixi manager runs `pixi lock`, which can execute arbitrary code from
conda package hooks. It now only updates `pixi.lock` when `pixi` is
included in the global `allowedUnsafeExecutions` option, following the same
pattern as the `mise` manager. When `pixi` is not allowed, the package file
is still updated but `pixi.lock` is left unchanged.
https://pixi.prefix.dev/latest/security/#4-treat-package-hooks-as-code-execution
* feat(config): add commitTrailers option
Renovate's only way to add git trailers today is `commitBody`, but it's
broken on Gerrit: Renovate appends its own `Renovate-Branch`/`Change-Id`
block after the body, so user trailers end up in a non-final message
block and are not real trailers per git-interpret-trailers rules.
This adds a `commitTrailers: string[]` option (each entry a full
`Key: value` line), standardizes Gerrit's own trailers through the same
mechanism so user trailers and platform trailers merge into one final
block, and verifies the result at runtime with `git interpret-trailers`
(commitlint's trailer-exists rule uses the same approach). The
`:gitSignOff` preset is migrated from `commitBody` to `commitTrailers`
so sign-off works correctly on Gerrit too.
* Simplify a bit
* Simplify docs even more
* Simplify another bit
* Add comment about rawExec
* Drop runtime commit trailer verification
Bypass simple-git only to emit a proactive warn log is not worth the
extra surface area. Config validation already enforces Key: value form.
* test(git): cover string commit message with trailers
Codecov patch failed on the partial ternary branch that normalizes a
string message before appending trailers.
* test(gerrit): fix trailers test after scm rework
Align the commitTrailers merge test with the post-rework Gerrit SCM:
use fakeSha helpers and drop the removed force flag.
* Improve wording on gitSignOff docs
* Validate compiled commitTrailers as well
* Improve trailers example
* Use isString instead
* Update lib/util/git/index.ts
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
* Update lib/workers/repository/onboarding/branch/create.ts
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
* Format code
* Fix type-check
* Fix tests
---------
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
As noted in #30714, and to make the Minimum Release Age page a
"one-stop-shop", we can generate the documentation accordingly.
Using an orange "maybe" for support helps nudge folks to checking which
registry they're using, and noting that it still doesn't necessarily
work, even if the Datasource supports it.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* feat(instrumentation): allow exporting OTLP JSON file
We've recently been investing in improvements to Renovate's
OpenTelemetry instrumentation to improve debuggability and
supportability.
However, not everyone has an immediately available OpenTelemetry
Collector, so the added instrumentation isn't useful to those users.
Instead, we can provide a way to export to the OTLP file format, which
provides a means to export the data to disk and then consume it later.
This will also support use-cases like running in a CI platform like
GitHub Actions and GitLab CI, where OpenTelemetry Collectors may not be
exposed in that environment, but a post-run execution can export it.
We now need to make sure that `RENOVATE_USE_CLOUD_METADATA_SERVICES` is
never set, as `isTracingEnabled` will now resolve true, and the Cloud
Metadata Resource Detectors will be used.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* fixup! feat(instrumentation): allow exporting OTLP JSON file
* fixup! fixup! feat(instrumentation): allow exporting OTLP JSON file
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* fixup! feat(instrumentation): allow exporting OTLP JSON file
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* feat(gitlab): add gitlab codeowners role support
* chore: use named group in roleRegex
* Update lib/config/options/index.ts
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
* Update lib/modules/platform/gitlab/roles.ts
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
* chore: rename getMembers to getGroupMembers
* chore: refactor getRoleMemberUsernames
* chore: adjust test chaining
---------
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
* feat(manager/npm): read private registries from pnpm-workspace.yaml
Honor the `registry` and `registries` settings (pnpm v11+) declared in pnpm-workspace.yaml, applying them to workspace catalog/override deps and member package.json deps. Registry values containing ${...} are ignored, matching pnpm v11.5.3+.
* refactor(manager/npm): share pnpm registry resolution across extract paths
Extract a single applyPnpmWorkspaceRegistries helper so both the
pnpm-workspace catalog path and the package.json extract path apply
registries through one chokepoint, with env-var registry URLs filtered
once and consistently.
* refactor(manager/npm): filter pnpm env-var registries in schema
Move the env-var registry filtering into the PnpmWorkspaceFile schema as a
transform so registries are filtered once at parse time, and use the Nullish
helper for the registry/registries fields.
* refactor(manager/npm): simplify pnpm-workspace check and log parse errors
* feat: add `--rebase-all-open-branches`
* feat: mark rebaseAllOpenBranches as cli: true explicitly
* feat: mark checkedBranches as cli: true explicitly
* fix(manager/nuget): detect MSBuild SDK updates in sqlproj files
MSBuild SDK versions in `<Sdk>`, `<Import Sdk>`, and `<Project Sdk>`
elements are exact pins, but NuGet versioning treats bare versions as
minimum ranges (`>=`). That caused dependencies such as
`0.1.19-preview` to resolve to the latest release and skip updates.
Apply hybrid versioning to all `msbuild-sdk` dependencies at extract
time: use strict `semver` when the pin is valid semver, otherwise fall
back to `semver-coerced` for non-standard NuGet version strings (e.g.
four-segment revisions). Also add `.sqlproj` to the default manager
file patterns for SSDT SQL projects.
Changes:
- Add `applyMsbuildSdkVersioning()` helper and wire it through all
msbuild-sdk extract paths (XML, global.json, single-csharp-file)
- Extend `managerFilePatterns` to match `.sqlproj` files
- Add extract, util, index, and integration tests
- Document `.sqlproj` and MSBuild SDK extraction in nuget docs/readme
* fix(manager/nuget): use bump range strategy for msbuild-sdk deps
Replace hybrid semver versioning for MSBuild SDK pins with a default
package rule (`matchDepTypes: msbuild-sdk`, `rangeStrategy: bump`) per
review feedback. Remove `applyMsbuildSdkVersioning()` from all extract
paths and update tests accordingly. Sort nuget doc file extensions
alphabetically.
When folks are using the pre-built Mkdocs site, it can be confusing that
the client-side rendered "latest" version of the Renovate CLI doesn't
match the version used for the pre-built docs.
As we have a version noted in the footer of the exact version of the
Renovate version these docs correspond to, we should recommend folks
lean on that instead.
Additionally, on the public docs.renovatebot.com site, we're always at
the version anyway, so it's not worthwhile showing this.
* added dart/pub constraintsFilter support
* updated documentation to include pub for constraintsFiltering
* only add extractedConstraints if its populated
* increased coverage
* handle non-nullable environment.sdk better
* feat(config): set `groupSingleUpdates=false` by default
Although it didn't seem like this may be a breaking change when we
introduced this[0], there have been a number of follow-up Discussions
reported that have indicated there has been some breakage from the
changes.
Instead of continually fixing forward, we can revert this back to an
opt-in feature.
Once it's stable, we can look at re-enabling it (most likely in a major
release, unless we're confident no breakage should occur).
[0]: https://github.com/renovatebot/renovate/pull/43629#issuecomment-4594201274
* fixup! feat(config): set `groupSingleUpdates=false` by default
renovate[bot]