This change introduces a heap size limitation for the Gradle daemon used
when updating the Gradle wrapper, defaults to 512m.
The heap size is limited to the globally configured limit, which
defaults to 512m. It can be configured on the repository level, but not
exceed the globally configured limit. A hard coded mimiumum heap size of
512m is enforced.
The configuration option is named `toolSettings`, which has two
properties for the maximum and initial heap size. See
`docs/usage/configuration-options#toolSettings` for more details.
Our intent for `onboardingAutoCloseAge` would be that the global
config would take precedence over the inherited config value.
Our implementation missed this, which means that inherited config could
then override the value, including disabling it.
To correct this, we can make sure that when using `getInheritedOrGlobal`
we only allow the inherit config option if it is lower than the global
option.
Co-authored-by: Claude Sonnet 4.5 <jamie.tanna+github-copilot@mend.io>
As noted in #40604, we're seeing cases where we need to wait
`onboardingAutoCloseAge+1` days until the onboarding PR will be
auto-closed.
To fix this, we can refactor `getElapsedDays` to optionally return a
floating point number, which we can then perform more careful
calculations against.
As we're now being a little more careful with timings being used for our
date comparisons, we need to make sure that Vitest fakes our timer
during these tests.
Instead of long floating-point numbers, we should use a 2 decimal
place value for log messages, as they're more readable to humans.
As part of future changes, we need to be able to specify on a
per-command level whether a `shell` should be used.
Before we do this, we should make it possible to provide the `shell`
specifier.
As part of future changes which will fix issues with Composer + Yarn 1
introduced by f430552de4, we need to find
a way to ignore command failure, on a per-command basis.
To do this, we can provide a refactor to introduce a new type,
`CommandWithOptions` which has the ability to specify whether to
`ignoreFailure`.
To make this less of a refactor than would otherwise require, we can
pass around a `(string | CommandWithOptions)[]`
(or a `string[]` or a `CommandWithOptions[]`) to be used, and use
helpers `asRawCommand` and `asRawCommands` to extract the underlying
command where necessary.
In the case a command's failure is being ignored, return the error code
in the `ExecResult`.
We also need to make sure that when executing in Docker, we still
provide the `|| true`s, otherwise we'll start to see commands failing
unexpectedly.
As part of future-proofing the `CommandWithOptions`, we can make sure
that it uses `string[]`s for the command it's representing, to avoid
re-parsing it.
* fix(jsonata): ensure all evaluations use a new environment
When evaluating a JSONata expression concurrently, specifically when reusing
an expression instance (as we do since we cache them), it's possible that
a second concurrent evaluate() call clobbers the `$` binding before the
first one has finished, which will make it use incorrect values.
Passing in a non-undefined bindings value causes JSONata to instead
create a new environment for each evaluate() call, preventing these conflicts.
Fixes#40311.
* fix(jsonata): concurrency issues by wrapping jsonata.Expression
* fix(jsonata): tweak return type and revert no-longer-necessary change
---------
Co-authored-by: secustor <sebastian@poxhofer.at>
* feat(http): Prevent writes of already cached responses
* Update repository-http-cache-provider.ts
* Update repository-http-cache-provider.ts
* Fix queue timing measurement in HTTP request
* Fix import type for HttpCache schema
* Add mutex to HTTP request to prevent race conditions
* Refactor is import to use isPlainObject directly
* Only use locks for GET and HEAD
* Return method name to the mutex key
---------
Co-authored-by: Jamie Tanna <jamie.tanna@mend.io>
As noted in #40242, without `shell` being passed around, this won't
correctly apply for Post Upgrade Tasks, and might break other usages.
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
After recent changes to remove `shell: true`, it's clear from #40231
that this breaks Containerbase's installing of tools, as we use the
`hash` shell built-in.
As we no longer need the `hash` call, we can remove it.
As part of a future change, we will optionally be passing around
command arguments.
To make this a simpler change, we can prefactor this to make sure we're
using the space-separated `spawnargs` for error messages.
As part of a future change, we will optionally be passing around
command arguments.
To make this a simpler change, we can prefactor this to pass around the
(empty) args array first.
As part of future changes to ensure that `shell` is disabled by default,
we should first enforce this for our `postUpgradeTasks`, which are
user-controlled and are more likely to contain shell-interpolated
variables.
We need to add a new `shell` type to pass around, as it was previously
not optional.
* fix(util/exec): migrate to `execa` for command execution
As part of a future change, we need to make sure that we have
cross-platform support for specific command executions.
By using `execa`'s functionality on top of `node:child_process`, we can
provide this functionality, as well as retain a consistent API with
internal users.
We need to make a couple of small tweaks to setting the `RawExecOptions`
as we're now bound by `readonly` properties.
As the `stdio` property's type is not exported, we can replace this with
an explicit setting of `stdin`, `stdout` and `stderr`.
This requires a number of test changes to make sure that the `stdin`,
`stdout` and `stderr` are set.
This doesn't migrate any calls under `tools`, as they can remain using
`node:child_process`.
* chore(util/exec): ignore floating promises `.on` calls
Since moving to use `execa`, we now have "floating promises" for the
`.on` method calls.
As we aren't handling them here, we can now mark them as `void` (as an
alternative to ignoring the ESLint rule).
This has been deprecated since 2022-07, and is unused as we only ever
use UTF-8.
In `tools/utils/exec.ts` we make sure to specify it explicitly, so we
don't get a Buffer returned.
* refactor(github): add GraphQL branch query adapter
Add infrastructure for querying GitHub branches via GraphQL:
- Add branches-query-adapter following the tags-query-adapter pattern
- Add GithubBranchItem type
- Export queryBranches function
- Register cache namespace
* style: fix prettier formatting
* test: add queryBranches coverage
* Refactor undefined checks to use `is.undefined`
Replace direct comparison of `undefined` with the `is.undefined` helper for consistency.
* refactor: use maxItems instead of maxPages
* fix(cache): use `bitbucket-server` as platform cache key
Change the Bitbucket Server platform cache key from `bitbucketServer`
(camelCase) to `bitbucket-server` (kebab-case) to match the platform ID.
Adds migration logic to automatically convert existing caches using
the old key to the new format.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
* Simplify
* Simplify more
* Update lib/modules/platform/bitbucket-server/pr-cache.ts
Co-authored-by: RahulGautamSingh <rahultesnik@gmail.com>
* Revert "Update lib/modules/platform/bitbucket-server/pr-cache.ts"
This reverts commit e564d91742.
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Co-authored-by: RahulGautamSingh <rahultesnik@gmail.com>
As part of ongoing work to improve OpenTelemetry instrumentation of
Renovate in #38609, we can introduce an instrumented call for each
external command execution.
This makes sure we cover the key functions used for command
execution - `rawExec` - across the codebase, which is used
under-the-hood by `exec`.
Because commands could include sensitive arguments (such as repo or
global secrets) we need to make sure we sanitize the span name.
Note that we don't add instrumentation to `tools/utils/exec.ts` as it's
only used for i.e. building the docs site, and isn't used as part of the
core Renovate CLI.
* skip on unknown reviewers instead of failing
* fix(onboarding): prevent secrets resolution
* revert
* use expect-error
* fix: type of onboardingConfig
* Update lib/config/types.ts
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
---------
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
fix: don't sign commits made in submodules created by test suite
The 'commit.gpgsign=false' configuration was already in place for some
tests in this file, but not all of them. I'm pretty sure that with this
change in place, there's no more commit signing happening in this test
suite.
* feat: add emojis for repo problem levels
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* feat: add emojis for repo problem levels
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* feat: add emojis for repo problem levels
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* feat: add emojis for repo problem levels
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* feat: add emojis for repo problem levels
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* feat: add emojis for repo problem levels
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* incorporate feedback
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* incorporate feedback
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* Update common.ts
* Update common.ts
* Update common.ts
---------
Signed-off-by: Adam Setch <adam.setch@outlook.com>
Now we have instrumented our Git operations with tracing, we can make
sure that users who are not using OpenTelemetry still get insights into
their Git operation usage using a debug log output.
Following how other insights are produced, we can introduce a new type
in `lib/util/stats` for `GitOperationStats`, which will track the
overall execution for each operation type, and output them in the same
style as we use for other timing reports.
At the end of a Renovate run, we'll then make sure that this is logged
into a debug log for further investigation.
To create the report, we can make sure that we introduce a new
OpenTelemetry `SpanProcessor`, which will run when we end our Run, and
store any Git operations in `GitOperationStats`.
This adapts code from GPT-4.1 and code from [0].
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
[0]: https://github.com/yurisouza/monitoria-sdk/blob/ca9d751fa7c3a785a04f87b8966bb782b4617021/src/adapters/nestjs/span-duration-tracker.ts#L18-L27
Jamie Tanna