* refactor(manager/pixi): extract shared pixi.lock update helper
* test(manager/pixi): cover shared pixi.lock helper directly
Add a dedicated lockfile.spec.ts that exercises updatePixiLockfile
directly (gate, package-file write branch, lockfile maintenance,
unchanged, constraint pass-through, and error handling), and slim the
pixi and pep621 call-site specs down to their own behavior: how each
derives the pixi constraint and that they delegate to the shared helper.
* 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
Convert SSH-style template URLs to their HTTPS equivalent when
constructing the packageName for the git-tags datasource lookup,
mirroring what the git-submodules manager does. This allows the
lookup to be authenticated via hostRules credentials on setups
which access the Git host over HTTPS only.
The answers file itself keeps the original URL, so local
'copier update' runs by developers continue to use SSH.
Discussed in #44528
* fix(github): include commitTrailers in platform-native commits
The GitHub platform-native commit path (platformCommit) recreates the
commit via the REST API using only message, so trailers from
commitTrailers / :gitSignOff were dropped even though prepareCommit
wrote them into the local commit.
* test: use codeBlock for multi-line commit trailer expectations
* Remove unnecessary comment
* refactor(gerrit): format commit message with shared helper
Use formatCommitMessage for Gerrit reserved trailers so the final
message is built the same way as the git and GitHub platform-native
paths, then clear trailers so prepareCommit does not append them twice.
* Revert "refactor(gerrit): format commit message with shared helper"
This reverts commit d230fa3802.
* refactor(git): fold commit trailers into the message before scm
Remove CommitFilesConfig.trailers so platforms only ever see a fully
formatted message. Workers call formatCommitMessage once; prepareCommit
and GitHub platform-native commits pass message through as-is. Gerrit
parses the existing trailer block to merge Renovate-Branch/Change-Id.
* refactor(git): drop formatCommitMessage helper
Trailers are already folded into message at the worker boundary, so the
shared formatter only re-joined strings. Inline that at the few call sites
and keep splitCommitMessage for Gerrit's reserved-trailer merge.
* revert: keep the minimal commitTrailers platform-native fix
Drop the later refactors (fold trailers into message, Gerrit changes,
splitCommitMessage). Keep formatCommitMessage shared by prepareCommit
and GitHub platform-native commits only; Gerrit is unchanged.
As found with recent changes to the Terraform manager, although we
generally have `lockFileMaintenance` being executed by an external
package manager being invoked by `exec(...)`, there are a few package
managers that do not do so.
To make it very clear how this happens, we can add a new field to the
Manager API, which will provide a means to document this.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* fix(datasource/go): resolve sourceUrl from goproxy Origin
Use the Origin field from the existing @latest proxy response so vanity
modules get a sourceUrl without a go-get request to the vanity host.
* Rework some comments
* Update lib/modules/datasource/go/releases-goproxy.spec.ts
Co-authored-by: Jamie Tanna <github@jamietanna.co.uk>
---------
Co-authored-by: Jamie Tanna <github@jamietanna.co.uk>
* fix(gerrit): use max available Code-Review vote value for autoApprove
* Update lib/modules/platform/gerrit/scm.ts
Co-authored-by: Felipe Santos <felipecassiors@gmail.com>
* refactor(gerrit): extract Code-Review label name into a constant
* fix(gerrit): skip Code-Review vote and warn if label is not defined on project
* test(gerrit): restore Code-Review+2 auto-approve test with a defined label
* docs(gerrit): shorten getAutoApproveLabelValue() comment
* fix(gerrit): use static log message with metadata object for logger.warn
* refactor(gerrit): extract GerritLabels type alias
---------
Co-authored-by: Felipe Santos <felipecassiors@gmail.com>
* feat(manager/mise): set depType for tools and task tools
Allow packageRules to match mise deps via matchDepTypes:
- tools for top-level [tools]
- task-tools for tasks.*.tools
* test(manager/mise): override RUST_197 depType in task extract cases
* Make the task tool dynamic
* Restore formatting
* Restore another formatting
* 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>
* feat(manager/mise): run mise lock in safe mode without allowedUnsafeExecutions
When `constraints.mise` pins a version that supports mise safe mode
(`MISE_SAFE=1`), run `mise lock` with safe mode enabled instead of
requiring `mise` in `allowedUnsafeExecutions`. Safe mode is a hard
boundary against project config executing code (templates exec/read_file,
_.source, hooks, tasks, asdf scripts, plugin installs are all refused),
so it — not the allowlist — protects the host.
The existing allowlisted path is unchanged: allowlisted repos run
`mise lock` exactly as before, without forcing safe mode, so configs
that legitimately execute code during locking keep working.
Safe mode also removes the need to pre-install node/npm/golang/ruby as
resolver tools, since npm version listing uses mise's built-in registry
HTTP client and go runs with GOTOOLCHAIN=local.
Refs: jdx/mise#11146 (safe mode), jdx/mise#11145 (lock --bump)
* fix: address oxlint and pin safe-mode min version to 2026.7.12
- logger.warn requires a static message with interpolated values in the
metadata object (oxlint rule); move the version into metadata
- set MISE_SAFE_MODE_MIN_VERSION to 2026.7.12, the expected first release
containing safe mode (merged after v2026.7.11)
* feat(manager/mise): use mise lock --bump for lock file maintenance
lockFileMaintenance means "update to the latest versions", but plain
`mise lock` only refreshes metadata for already-locked versions. Use
`mise lock --bump` so fuzzy selectors (e.g. node = "22") advance to the
latest matching version. `--bump` requires the same minimum mise version
as safe mode, so it is gated on the mise constraint and falls back to a
plain refresh otherwise.
Generalizes the version-gate helper (miseConstraintGuarantees) shared by
safe mode and --bump.
* refactor(manager/mise): detect mise version at runtime instead of via constraints
Determine safe-mode / --bump support by running `mise version` (which
does not load or execute project config) rather than requiring a pinned
`constraints.mise`. This works off whatever mise is actually installed,
so no extra configuration is needed.
The probe is skipped on the allowlisted, non-maintenance path, where the
version cannot change the outcome — keeping that hot path unchanged.
* feat(manager/mise): skip mise trust in safe mode
Safe mode now makes an untrusted config fully inert and no longer
requires trust to load it (jdx/mise#11151), so on the safe-mode path
`mise trust` is unnecessary and is skipped — `mise lock` runs with
`MISE_SAFE=1` alone. The allowlisted path is unchanged and still runs
`mise trust`.
* feat(manager/mise): confirm safe mode min version against v2026.7.12 release
MISE_SAFE=1 safe mode and `mise lock --bump` first shipped in mise
v2026.7.12 (released 2026-07-23), confirming the assumed
MISE_SAFE_MODE_MIN_VERSION. Resolve the pending-release TODO and align
the test version fixture with the real release date.
Validated end-to-end against the real v2026.7.12 binary: `mise version`
output matches the parser, `MISE_SAFE=1 mise lock` refreshes an untrusted
config without trust, `mise lock --bump` advances fuzzy selectors, and
project [env] is ignored under safe mode.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* test(manager/mise): cover mise version probe failure path
Add a test for the detectMiseVersion catch branch (exec throwing), so the
non-allowlisted path falls back to conservative behavior. Restores 100%
patch coverage for the mise manager.
* Update lib/modules/manager/mise/readme.md
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
* Update lib/modules/manager/mise/readme.md
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
* docs(mise): fix safe mode section link
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
fix(platform/gitlab): retry MR creation on transient source_branch race
GitLab occasionally rejects a merge request POST with
`400 {"message":{"source_branch":["does not exist"]}}` immediately after
a branch push succeeds, because the freshly pushed ref is not yet visible
to the API due to Gitaly eventual consistency. The request was not
retried, leaving an orphaned branch until the next run.
Extend the existing `calculateRetryDelay` hook (which already retries
transient `409 Resource lock` POST errors) to also retry this
`400 source_branch does not exist` case, reusing got's bounded
exponential backoff.
* feat(lint): add renovate/prefer-fs-util and renovate/prefer-luxon rules
Two shared-util substitution rules, both at warn level:
- renovate/prefer-fs-util flags value imports of fs, node:fs,
fs/promises, node:fs/promises, fs-extra and fs-extra/esm in lib/
source files outside lib/util/fs/, pointing to the scoped helpers
from lib/util/fs. Spec files and type-only imports are exempt.
A config-only change via no-restricted-imports was considered but
rejected: that rule is at error severity globally and per-path warn
severity is not expressible, so the 13 existing call sites would
break the baseline.
- renovate/prefer-luxon flags new Date(...) and Date.now() in lib/
source files, pointing to Luxon per best-practices. Date/time
utility modules (lib/util/date, lib/util/pretty-time,
lib/util/timestamp) and spec files (vi.setSystemTime etc.) are
exempt.
Baseline: 13 prefer-fs-util and 45 prefer-luxon warnings, zero errors.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor: use Luxon instead of new Date() at remaining call sites
Fixes all renovate/prefer-luxon violations for `new Date(...)`:
- `new Date().toISOString()` -> `DateTime.utc().toISO()` (byte-identical
output) in the http cache provider, schedule logging and PR cache.
- `new Date()` -> `DateTime.now().toJSDate()` for the git commit-date
fallback and the rubygems `syncedAt` markers (same `Date` values).
- rust-release-channel now computes the Rust 1.0 release date and nightly
version dates via `DateTime.utc(...)`; previously `new Date(y, m, d)`
used the local timezone while the epoch used UTC, so the comparison was
timezone-dependent at the boundary date. Tests run with TZ=UTC, where
behavior is unchanged.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor: use lib/util/fs helpers in repository worker
Fixes renovate/prefer-fs-util violations outside bootstrap code:
- `fs.ensureDir()` -> `ensureDir()` from lib/util/fs (same fs-extra call
underneath; it no-ops on an empty dir name, so the repository worker
spec now simulates the init failure via a rejected `initRepo` instead
of relying on `fs.ensureDir('')` throwing).
- `fs.remove(privateCacheDir())` -> `cachePathExists()` + `rmCache()`,
keeping the remove-if-present semantics while asserting cacheDir
containment.
Two call sites keep raw imports with reasoned disable comments:
- lib/util/modules.ts synchronously enumerates Renovate's own installed
module directories at import time.
- lib/util/cache/package/impl/sqlite.ts receives cacheDir as an explicit
argument during global initialization, before GlobalConfig (which the
scoped cache helpers resolve against) contains cacheDir.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* feat(lint): promote prefer-fs-util and prefer-luxon to error
Both rules are narrowed to what is actually accepted practice before
being promoted:
prefer-luxon no longer flags `Date.now()`: it returns UTC-based epoch
milliseconds used for elapsed-time measurement and TTL arithmetic, which
is timezone-independent by construction. The mined reviewer feedback
behind this rule ("use Luxon for date arithmetic outside util") targets
timezone-dependent date construction/formatting, which cannot occur with
a raw millis number; the rule keeps flagging `new Date(...)`.
prefer-fs-util exempts code that legitimately needs raw fs access
because the scoped lib/util/fs helpers resolve against GlobalConfig
localDir/cacheDir, which does not exist yet or does not apply there:
- lib/logger/: log-file streams at user-configured system paths during
bootstrap; lib/util/fs also depends on the logger (import cycle).
- lib/workers/global/: creates baseDir/cacheDir themselves and
reads/writes user-supplied paths before GlobalConfig is seeded.
- lib/config-validator.ts: standalone CLI without GlobalConfig.
- lib/util/git/: owns the localDir lifecycle (clone, emptyDir, symlinks)
and private-key files with sync cleanup on process exit.
Also fixes a pre-existing tsc error in prefer-fs-util.js: `importKind`
is a TypeScript-ESTree extension missing from eslint's base AST types.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor(fs): make rmCache ignore missing paths
All rmCache callers use it for cleanup, where a missing path is a
no-op, so bake force: true in instead of guarding call sites with
an existence check.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor(linters): exempt lib/instrumentation from prefer-fs-util
`lib/instrumentation/file-exporter.ts` landed on main while this branch
was open and imports `node:fs/promises` directly.
The exporter writes to a user-configured system path
(`RENOVATE_TRACING_FILE_EXPORTER_PATH`) outside `localDir`/`cacheDir`,
so the scoped helpers do not apply. `lib/instrumentation` is also
deliberately kept out of the module graph of instrumented libraries
(see the `⚠️` note in `lib/renovate.ts`), so it must not pull in
`lib/util/fs` and its config/logger dependencies. Exempt the directory,
as is already done for `lib/logger`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
* docs: shorten doc
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
As part of follow-up changes, we'll need to call the checks in multiple
places, so should prefactor these into helper methods.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
As part of follow-up changes, we'll use these functions to centrally
determine as to whether to execute `minimumReleaseAge` or
`minimumConfidence` checks against a given updateType.
For now, we can wire this into our documentation tests, to make sure
that this stays in sync with `isMinimumReleaseAgeApplicable`.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
When GitHub returns 'GH013: Repository rule violations found' during
a push, the failure is currently silently swallowed by handleCommitError
whenever the changeset touches a file under .github/workflows/. The
existing swallow was intended for the narrow case of an App token
missing the 'workflows' scope, but it also masks unrelated ruleset
violations such as:
- GITHUB PUSH PROTECTION 'File path is restricted'
- Secret scanning push protection
- Signed commit / branch-naming / tag-deletion rulesets
Self-hosted operators cannot see these failures in aggregated log
reports because Renovate logs at info level, marks the branch as
aborted, and continues. Repositories that are effectively 100%
blocked by a ruleset appear healthy.
Detect the 'GH013' token before the workflow-files silent-swallow and
throw a CONFIG_VALIDATION error - mirroring the treatment already
applied to GH003 (force-push denied) and 'protected branch hook
declined'. This flags the repository as failing, populates
validationError / validationMessage so the failure reason is visible
in the repository summary, and lets any downstream reporting pick it
up as a real failure instead of an info-level abort.
Adds tests to lib/util/git/errors.spec.ts covering:
1. A GH013 Push Protection error whose changeset is entirely under
.github/workflows/ is thrown as CONFIG_VALIDATION with the
expected validationSource / validationError / validationMessage.
2. A generic non-GH013 workflow-file remote rejection still returns
null (existing swallow behaviour preserved).
* feat(lint): add renovate/zod-schema-location and renovate/prefer-json-pipe rules
Backlog item #23: reviewers repeatedly ask for consistent Zod schema
structure. Two new oxlint JS-plugin rules, both at "warn":
- renovate/zod-schema-location flags `export const X = <zod schema>` at
module scope in lib/modules/**/ files that aren't schema.ts (or a
colocated schema/ directory), reusing the leftmost-identifier schema
detection from zod-schema-naming.js / prefer-nullish-util.js. Only
exported top-level schemas are flagged — non-exported ones are treated
as intentionally local/trivial (e.g. tightly coupled to file-local
helpers), which keeps the rule's signal high.
- renovate/prefer-json-pipe flags `Schema.parse(JSON.parse(x))` /
`Schema.safeParse(JSON.parse(x))` and suggests `Json.pipe(Schema)` from
lib/util/schema-utils instead.
A third mined slice (require a matching `z.infer` type export for every
exported schema) was evaluated and skipped: ~275+ exported schema-like
consts in schema.ts files vs. 231 existing z.infer exports repo-wide is
too high a mismatch to flag mechanically without heavy per-site
judgment, so it would be mostly false positives.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor: fix a clean subset of renovate/zod-schema-location and renovate/prefer-json-pipe violations
renovate/prefer-json-pipe: fixed all 5 safe `.parse(JSON.parse(...))`
call sites (bazel datasource, generate-mise-registry script, a hook
spec) by switching to `Json.pipe(Schema).parse(...)`. Left the 2
`.safeParse(JSON.parse(...))` sites (pretooluse-check.ts,
github-query-items.ts) unfixed: JSON.parse throwing before safeParse is
reached today crashes the script, whereas Json.pipe folds the bad-JSON
case into a graceful `{ success: false }`, which is an observable
behavior change, not just a mechanical rewrite.
renovate/zod-schema-location: fixed the one clean, self-contained
violation (platform/github's GithubIssue schema, moved into the
already-existing platform/github/schema.ts) as a representative
example. Left the other 20: they require moving exported schemas out of
files where they're built from local helper functions/config tables
(manager/github-actions/community.ts) or restructuring an entire
directory into a new schema.ts with import-graph updates across many
files (manager/bazel/rules/*.ts, manager/bazel-module/parser/*.ts) —
real refactors needing per-site judgment, not mechanical fixes.
Both rules stay at "warn": renovate/prefer-json-pipe has 2 remaining
violations that shouldn't be auto-fixed, and renovate/zod-schema-location
has 20.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor: resolve remaining prefer-json-pipe and zod-schema-location findings
- github-actions: move the derived `CommunityActions` union into the
existing colocated `schema.ts`; the action config table and the
`actionSchema` builder stay in `community.ts` and are now exported.
- tools/docs: fold `JSON.parse` + `safeParse`/rethrow of the `gh` CLI
output into `Json.pipe(...)`. Invalid JSON now surfaces as a ZodError
instead of a SyntaxError; the only consumer catches generically, so
behavior is preserved.
- tools/agents/hooks: keep `JSON.parse` + `safeParse` with a reasoned
disable comment — hook scripts must stay dependency-light, and the
`Json` helper lives in lib/util/schema-utils, which drags in the full
lib import graph (logger, yaml, toml).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* feat(lint): enforce zod-schema-location and prefer-json-pipe as errors
Narrow `renovate/zod-schema-location` to files whose directory already
contains a colocated `schema.ts`. The mined reviewer feedback ("move
this to schema.ts") presumes the module follows that convention and the
schema leaked into a logic file. Modules that deliberately export
schemas from differently-named schema-only files — bazel `rules/*.ts`
Target schemas, bazel-module `parser/fragments.ts` — are a different,
accepted layout, not "schema mixed into logic", and are no longer
flagged.
With that narrowing and the preceding migrations, both rules are clean
repo-wide, so promote them from "warn" to "error".
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* refactor: drop GithubIssue re-export from issue.ts
Consumers now import the schema directly from schema.ts.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(lint): register zod-schema-location rule
The rule registration was lost while merging main, so oxlint failed to
parse .oxlintrc.json with "Rule 'zod-schema-location' not found in plugin
'renovate'". Re-add the import and rules entry, and restore alphabetical
ordering for prefer-json-pipe.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* fix(lint): allow sync fs in zod-schema-location rule
ESLint rules execute synchronously, so the sibling `schema.ts` lookup
cannot use async fs. Silence `no-sync` with a justification.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* chore: add zod schema for gitlab getProjectMembers
* chore: swap getRoleAccessLevel regex for startsWith and slice
* chore: drop unnecessary as const
Similar to da47cb0688, I'd missed this
from 61e4c9c2d1, which leads to old
usages of facebook/react-native no longer having their changelog
skipped, which is not correct.
* fix(preset/monorepo): re-add old facebook/react URL
I'd missed this from 61e4c9c2d1, which
leads to old PRs no longer being grouped, which is not correct.
* fixup! fix(preset/monorepo): re-add old facebook/react URL
* 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>
fix(data): update react and react-native source URLs to react/react org
The react and react-native repositories moved from the facebook org to
the react org on GitHub
See https://github.com/renovatebot/renovate/discussions/44772
* docs(manager): make sure that Supported Datasources are de-duped and sorted
As noted in #44764, we otherwise end up with a lot of duplicated
entries for `renovate-config`.
We can also sort them to make ti a slightly more readable list.
* chore(manager/renovate-config): dedupe `supportedDatasources`
* 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>
Niels Pardon