* feat(exec): register bazelisk as containerbase tool
* test(bazel-module): add failing tests for updateArtifacts
* feat(bazel-module): implement updateArtifacts for lockfile support
* feat(bazel-module): export updateArtifacts from manager index
* fix(bazel-module): address code review feedback
- Use logger.warn instead of debug for artifact errors
- Add utf8 encoding to readLocalFile calls
- Use getSiblingFileName for lockfile path derivation
- Add empty updatedDeps guard
- Strengthen test assertions
* docs(bazel-module): document lockfile support
* Update lib/modules/manager/bazel-module/index.ts
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
* Apply suggestions from code review
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
* fix(bazel-module): address review feedback
- Remove unnecessary afterEach in tests
- Use partial<StatusResult> for all StatusResult mocks
- Add lockfile maintenance support
- Export supportsLockFileMaintenance flag
* fix(bazel-module): handle untracked lock files and clarify docs
Check status.not_added alongside status.modified for lock file changes,
matching the pattern used by other managers (composer, gomod, etc.).
Clarify that Bazelisk (not Renovate) reads .bazelversion. Add test for
lockfile maintenance with no changes.
* feat(bazelisk): implement updateArtifacts for MODULE.bazel.lock
When the Bazel version in .bazelversion changes, run `bazel mod deps` to
regenerate MODULE.bazel.lock and return the updated lockfile as an artifact.
* feat(bazelisk): add lockfile maintenance support
* docs(bazelisk): add lockfile support section linking to bazel-module docs
* refactor(bazel-module): extract shared lockfile update helper
* refactor(bazel-module): delegate lockfile update to shared helper
Replace inline lockfile update logic in artifacts.ts with a call to the
shared updateBazelLockfile() helper, and update tests to mock the helper.
* refactor(bazelisk): delegate lockfile update to shared helper
Replace inline lockfile update logic in bazelisk/artifacts.ts with a
call to the shared updateBazelLockfile() helper from bazel-module/lockfile.ts.
* fix(bazelisk): use index.md for cross-manager docs link
The docs pipeline renames readme.md to index.md, so cross-manager
links must reference index.md to pass the docs link checker.
* feat(bazel-module,bazelisk): support bazelisk version constraint
Pass config.constraints.bazelisk through to toolConstraints so users
can pin the bazelisk version if the newest release is broken.
* fix(bazel-module): rename lockFile to fileName in ArtifactError
Upstream renamed lockFile to fileName in ArtifactError type (#41631).
---------
Co-authored-by: Michael Kriese <michael.kriese@gmx.de>
* feat(managers/npm): allow specifying `toolSettings.nodeMaxMemory`
As noted in #40942, we're seeing an increase in memory usage across
`pnpm` and `yarn` users in Mend-hosted apps.
To allow limiting the maximum memory that any `node` child processes
will use, we can add a new `toolSettings.nodeMaxMemory` to (hopefully)
mitigate this.
Similar to the `toolSettings.jvmMaxMemory`, the self-hosted
administrator can set a maximum, which cannot be exceeded by repo-level
configuration.
* fixup! feat(managers/npm): allow specifying `toolSettings.nodeMaxMemory`
To prefactor this to be a simpler change in the future as we add new
functionality to `getToolSettingsOptions`, we can:
- wrap the JVM settings in its own `describe` block
- use `toMatchObject`, so new default values don't break existing tests
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.
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.
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.
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.
* docs(constraints): clarify that `binarySource=global` ignores them
Although this is a somewhat commonly known behaviour, it's worth making
this more clear, by clarifying this in the `constraints` docs, as well
as add a debug log.
* docs(constraints): simplify message
As noted by Michael, these may not be user-facing `constraints`, but the
constraints a Manager sets.
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
---------
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
Tim Tran