chore(deps): update all-dependencies (major)

[renovate]

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Type	Update	Change	Age	Confidence
grafana/k6		major	1.6.1 → 2.1.0
pinact	tools	major	3.8.0 → 4.1.1
pnpm (source)	tools	major	10.32.1 → 11.18.0

---

Release Notes

suzuki-shunsuke/pinact (pinact)

v4.1.1

Compare Source

Dependency Updates

#​1634 Update Go to v1.26.5

#​1659 Update module github.com/suzuki-shunsuke/ghtkn-go-sdk to v0.5.0
#​1622 Update module github.com/urfave/cli/v3 to v3.10.1
#​1633 Update module github.com/google/go-github/v88 to v89

#​1646 Update dependency sigstore/cosign to v3.1.2
#​1653 Update dependency anchore/syft to v1.49.0
#​1657 Update dependency goreleaser/goreleaser to v2.17.1

v4.1.0

Compare Source

Features

#​1578 Update ghtkn-go-sdk to v0.3.0 for backend and disable device flow support

v4.0.0

Compare Source

⚠️ Breaking Changes

#​1540 Removed the -review option

Output SARIF and pass it to reviewdog. This has been announced previously.

pinact run -format sarif |
  reviewdog -f sarif -name pinact -reporter github-pr-review

#​1540 Always output diff

Even if you specify -diff=false, it is ignored.

#​1540 -diff and -check are now aliases for -fix=false

This simplifies the logic, making it easier to understand and less prone to bugs.

#​1540 -verify is now an alias for --verify-comment

-verify was unclear about what was being verified, so it has been renamed for clarity.
However, -verify is kept as-is to maintain backward compatibility.

#​1458 #​1558 Version comments are now required @​ManuelLerchnerQC

For SHAs without a version comment, pinact automatically adds a version comment (validation error if -fix=false).

$ pinact run test.yaml
test.yaml:1
- - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
+ - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2

Specifying a version comment makes it easier to see which version is being used, and makes it easier for tools like Renovate and Dependabot to update.
It also has security implications.
For GitHub Actions versions, you can also specify the SHA of a commit in a fork.
This means it could point to a malicious commit in a fork.
If you specify only the SHA without a version comment, you cannot tell whether it is the SHA of a commit in a fork.
By requiring version comments, you can verify that the version comment matches the SHA using the --verify-comment option.
Even if a fake version comment is added to a fork's SHA, it can be detected by --verify-comment.
An attacker could also create a tag pointing to a fork's SHA, but creating a tag requires write permission, which raises the bar for attacks, so this can be said to improve security.
Of course, this is only meaningful if you verify with --verify-comment, so it is recommended to run pinact with --verify-comment in CI.

Features

#​1540 -no-api: support for offline validation
#​1540 You can now check whether the version being used satisfies min age, not just newer versions
#​1540 More flexible min age support via rules
#​1540 #​1542 #​1543 Support for a global configuration file
#​1435 Automatic correction of version comments via -verify-comment @​ManuelLerchnerQC
#​1547 #​1552 #​1557 #​1562 -diff-file: limit pinact's targets to only the changed lines

-no-api: support for offline validation

If you just want to check whether something is pinned, you don't really need to use the GitHub API, but previously the GitHub API was called.
With the -no-api option, you can validate without calling the GitHub API.
However, since API calls are currently essential for fixing code (this may change in the future if caching is supported), you need to specify either -fix=false or -format sarif.
Implicitly treating it as -fix=false could cause behavior to change and become a breaking change when caching is supported, so it must currently be specified explicitly.

You can now check whether the version being used satisfies min age, not just newer versions

For example, you can run it in CI against modified lines to check whether any dangerous versions that do not satisfy min age are being used.
This is not checked by default, but is checked when you run pinact run --verify-min-age or pinact run -min-age <min age>.

More flexible min age support via rules

min age can now be configured in the configuration file.
Additionally, by using rules, you can apply settings such as min age to specific actions.

min_age:
  value: 7 # default setting
rules:
  # Allow latest for suzuki-shunsuke's actions
  - ignore: true
    conditions:
      - expr: |
          ActionRepoOwner == "suzuki-shunsuke" && ActionVersion == "latest"
  # Set min age to 0 for actions/checkout
  - min_age: 0
    conditions:
      - expr: |
          ActionRepoFullName == "actions/checkout"

For rules, conditions are evaluated per rule, and the settings are applied if matched.
You can write multiple conditions, and the settings are applied if any one of the conditions matches.
expr follows https://expr-lang.org/docs/language-definition. Please read the documentation for details.
The settings of rules listed later in rules take precedence.

Support for a global configuration file

[!WARNING]
If you have set the PINACT_MIN_AGE environment variable in ~/.bashrc, ~/.zshrc, etc., it is recommended to remove it and use a global configuration file instead.
PINACT_MIN_AGE takes precedence over the configuration file, so it overrides the project's settings.
On the other hand, global settings are merged with lower priority than the project's settings.
If you want to enforce the setting, PINACT_MIN_AGE is suitable, but for default settings, a global configuration file is more appropriate.
Note also that environment variables do not allow flexible settings like rules.

A global configuration file is now supported.
The file path is searched in the following order of priority:

1. $PINACT_GLOBAL_CONFIG
2. ${XDG_CONFIG_HOME}/pinact/pinact.yaml
3. ${HOME}/.config/pinact/pinact.yaml

On Windows:

1. $PINACT_GLOBAL_CONFIG
2. %APPDATA%\pinact\pinact.yaml

rules are prepended before the rules in the project configuration file.
So project settings take precedence over global settings.

Automatic correction of version comments via -verify-comment

If the SHA and the version comment do not match, the version comment is automatically corrected to match the SHA.
Previously, it would just return an error, but now it is automatically corrected.

-diff-file: limit pinact's targets to only the changed lines

If you specify a file in Unified Diff Format via -diff-file, you can limit pinact's targets to only the changed lines.
By passing the PR's diff file in PR CI, you can reduce unnecessary API calls and prevent corrections or errors from code unrelated to the PR's changes.
This makes it easier to introduce pinact via Required Workflow across an entire GitHub Organization of a large development organization.
To improve the overall health of a development organization, it is desirable to introduce pinact via Required Workflow.
However, if you suddenly introduce pinact as a Required Workflow in an Organization that has a lot of originally unpinned code, errors and corrections unrelated to the PR's changes will occur everywhere, causing confusion.
When errors occur in places unrelated to the PR's changes, the PR author thinks "what is this error?", "wait, do I have to fix this? It's unrelated to this PR so I want to split the PR, but creating a PR is a hassle."
It is also possible that the same error occurs in multiple PRs, and each one independently performs redundant fixing work.
Inquiries about errors come in from various teams, generating unnecessary costs.
If you try to fix everything before introducing the Required Workflow, it takes time to introduce, and during that time the bad situation continues where new unpinned code keeps increasing.

On the other hand, if you can fix and validate only the lines changed in a PR, the PR author can more easily accept making the fix, and there is no need to split the PR.
However, this alone does not pin existing code, so in parallel with this, you still need to run pinact against each repository and create PRs.

How do you generate the file specified by -diff-file? You can easily generate it using the action https://github.com/suzuki-shunsuke/pr-unified-diff-action.

- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
  with:
    persist-credentials: false
- uses: suzuki-shunsuke/pr-unified-diff-action@c932c1df5f577028d8ca05d2d3c0c059072d8821 # v0.0.1
  id: diff
- uses: suzuki-shunsuke/pinact-action@896d595f299e71d65b9d28349d6956abe144390a # v3.0.0
  with:
    diff_file: ${{ steps.diff.outputs.diff_path }}

v3.10.1

Compare Source

🐛 Bug Fixes

#​1535 pin uses lines with multiple spaces after the YAML list dash

v3.10.0

Compare Source

Features

#​1530 Support pinning branches to latest stable tags by the --branch-to-tag option

The default behabiour isn't changed.
By default, pinact doesn't pin branches such as main or master.
If you want to pin specific branches, you can use the --branch-to-tag option.

e.g.

pinact run --branch-to-tag '^main$' --branch-to-tag '^release/.*$'

v3.9.2

Compare Source

Fixes

#​1493 Preserve original line endings when updating workflows

v3.9.1

Compare Source

v3.9.0

Compare Source

Features

#​1365 Make version separator configurable via configuration file @​ReenigneArcher
#​1372 Make version separator configurable via command line option and environment variable

🐛 Bug Fixes

#​1359 Fix a bug that -log-color doesn't work

Others

• docs: fix readme for ignore_actions[].ref by @​nasa9084 in #​1323
• docs: fix readme for correct GHES_API_URL by @​maruloop in #​1324
• docs(INSTALL): add mise alternate installation documentation by @​jylenhof in #​1331

pnpm/pnpm (pnpm)

v11.18.0: pnpm 11.18

Compare Source

Minor Changes

• Fixed an installed optional dependency being left without one of its own required dependencies. When a package reached through optionalDependencies is installable on the current system but one of its regular dependencies is not, a lockfile-based install skipped that dependency and installed the parent anyway, so importing the parent failed with MODULE_NOT_FOUND. The dependency is now installed, and an install-check warning reports the incompatibility. A dependency is still only skipped when every path to it is optional, or when the package that pulls it in was itself skipped #​13286.

• pnpm setup now appends PNPM_HOME and the global bin directory to the GitHub Actions environment files (GITHUB_ENV and GITHUB_PATH), so later steps in the same job can run pnpm add --global and other global commands #​9191.

• Added support for publishConfig.name, which publishes a package under a different name than the one its manifest carries in the workspace. It is for a project whose published name is already taken by a sibling project, which otherwise has to be renamed by a build step just before publishing. Only the published artifact is renamed — dependents, pnpm-lock.yaml, and release tooling keep addressing the project by its manifest name — and the new name reaches the packed manifest, the tarball filename, and everything that addresses the package at the registry: the already-published check of pnpm publish -r, its registry selection, and the release-planning probes of pnpm change status and pnpm version -r #​13345.

• pnpm self-update no longer takes any instruction from the project it is run in:

  • pnpm is fetched through the same trusted registry and auth configuration used when switching pnpm versions, so a project .npmrc or pnpm-workspace.yaml can no longer redirect the download or attach credentials to it, and the project's default .pnpmfile.(c|m)js is no longer loaded. Pnpmfiles from trusted sources (the pnpmfile setting, the global pnpmfile, config dependencies) still apply.
  • The minimumReleaseAge settings in pnpm-workspace.yaml no longer affect self-update. They still govern the project's own dependencies; for self-update the cooldown now comes from the built-in default, your global config, a PNPM_CONFIG_* environment variable, or a command-line flag. This fixes self-update failing inside a workspace that raises the cutoff while succeeding everywhere else, and stops a repository from either waiving the cooldown or keeping you on an outdated pnpm by raising it.
  • The same applies to the trustPolicy settings and to ci: a project can no longer weaken the trust check that guards the pnpm download, nor re-enable the confirmation prompt that a CI run suppresses.

  When self-update refuses a version that is younger than the cutoff, an interactive run now offers to update anyway; non-interactive runs still fail. CI never prompts, even on a runner that attaches a TTY.

Patch Changes

• Fixed pnpm licenses list to report every version when the same package is installed under multiple aliases pnpm/pnpm#13438.

• Sort pnpm dedupe --check snapshot changes for stable output across pnpm implementations.

• Strip Unicode formatting characters from registry- and manifest-derived terminal output.

• Speed up installs after compatible catalog or direct dependency range changes by retaining the locked version without resolving the dependency graph again.

• Speed up installs after safe override changes by reusing unambiguous compatible dependency resolutions, pruning obsolete dependencies, applying independent replacements and removals together, and handling parent-scoped "-" overrides without full lockfile resolution.

• Installing a local file: directory dependency with the global virtual store enabled no longer fails with TypeError: Cannot read properties of undefined (reading 'split') #​13335.

  Local directory dependencies — file: directories and injected workspace packages — now get a global-virtual-store slot of their own per project. They used to share one slot across every project that depended on a directory of the same name, so a project could end up linked to another project's copy of the dependency.

• The Workspace column of pnpm update --interactive now falls back to the project's path when its name is only whitespace, as it already did for a missing or empty one — all three render an equally blank label otherwise.

• Checking GitHub Actions dependencies for updates is now opt-in for every command. Neither pnpm outdated nor pnpm update reads the workflow files unless --include-github-actions is passed or update.githubActions is set to true in pnpm-workspace.yaml. Reading them runs git ls-remote against every referenced repository, which fails in environments where GitHub is not reachable the way pnpm assumes (a GitHub Enterprise Server, a custom certificate authority, or an offline network) #​13254.

  pnpm outdated accepts the --include-github-actions option too.

• pnpm update --interactive now measures its table in terminal columns rather than in characters. A package name, workspace name, or version containing wide characters (CJK, most emoji) no longer knocks its row's columns out of line with the rest of the group, and a wide character in a version no longer aborts the command with Subject parameter value width cannot be greater than the container width #​13357.

• The Workspace column of pnpm update --interactive is more informative in two cases. A dependency outdated at the same version in several workspace projects is offered as one choice, since selecting it updates every project — that choice now names all of them instead of only the first. And a workspace project without a name is now labelled with its path rather than left blank, so several unnamed projects can be told apart.

• An auto-installed optional peer is no longer hoisted at a version the workspace root's own dependency on that package excludes. resolvePeersFromWorkspaceRoot already made the workspace root's specifier decide which version a missing required peer is installed at; the optional-peer picker ignored it and always took the highest version present anywhere in the graph. In a workspace whose root pins postcss: 8.5.10, an importer that depends on webpack and declares no postcss of its own got postcss@8.5.22 hoisted for terser-webpack-plugin's optional postcss peer, leaving two postcss@8.5.x instances in the graph #​13320.

• overrides now also govern peers that pnpm auto-installs. Previously an override only rewrote dependencies declared in a manifest, so a peer nobody declares — installed because autoInstallPeers is on — resolved against its declared peer range and could bring in a second copy of the very package the override pinned. For example, with overrides: { react: npm:react@19.2.0 } and a lone lucide-react dependency, pnpm installed react@18.3.1; it now installs the pinned react@19.2.0 #​13320.

• Under resolvePeersFromWorkspaceRoot, a workspace root dependency declared with link: or file: (or the path form of workspace:, such as workspace:../pkg) now satisfies another project's missing peer dependency at the linked package's own version, instead of being hoisted as a path. Those specifiers are relative to the project that declares them, so the same specifier reached a different directory — or none — from the project the peer was hoisted into, leaving a broken link. The root now has the same authority over the peer as it has when it declares the package with a version range #​13373.

• Installs through a pnpr server now apply the project's whole verification policy. minimumReleaseAgeExclude, minimumReleaseAgeIgnoreMissingTime, trustPolicy, trustPolicyExclude, trustPolicyIgnoreAfter, and trustLockfile were ignored, so excluded packages were still held back and a lockfile containing them could be rejected.

  trustPolicy: no-downgrade no longer fails with TRUST_POLICY_INCOMPATIBLE_WITH_PNPR when a pnpr server is configured.

  --frozen-lockfile and --no-prefer-frozen-lockfile are now honored on the pnpr path, instead of resolving and rewriting the lockfile anyway. Since frozenLockfile defaults to true on CI, a CI install through a pnpr server now fails on an out-of-date lockfile rather than updating it.

• Workspace installs through a pnpr server no longer crash with Cannot read properties of undefined (reading 'filter') after linking, when minimumReleaseAge is active #​13275.

• Fixed pnpm dedupe updating valid catalog resolutions when another matching version exists in the lockfile.

• pnpm -r run "/pattern/" --no-bail no longer exits zero when one of a project's matched scripts fails and a later one passes. The run summary carries a single status per project, and the passing script overwrote the recorded failure.

• Restored the store block a first install prints, naming how packages were materialized and where the stores live #​13315:

  Packages are hard linked from the content-addressable store to the virtual store.
    Content-addressable store is at: ~/.local/share/pnpm/store/v11
    Virtual store is at:             node_modules/.pnpm
  

• The root project's pnpm:devPreinstall script now runs before resolution and linking, as it does in pnpm 11. It is skipped under --ignore-scripts, --lockfile-only and --dry-run, by pnpm fetch and pnpm rebuild, and by a repeat install that is already up to date. Workspaces that use the hook to prepare state the install depends on — such as next.js, which generates a placeholder next bin with it — were left with dependents linked against files that were never created #​13313.

• Prevented pnpm dedupe --check from removing an incompatible node_modules directory.

• pnpm update --workspace no longer links dependencies the user never named:

  • Running it with updateConfig.ignoreDependencies configured no longer fails with ERR_PNPM_WORKSPACE_PACKAGE_NOT_FOUND for a dependency that is only published to the registry. Such dependencies keep their specifiers, as they already did when no dependencies were ignored.
  • Passing package selectors that match no direct dependency no longer falls back to linking every workspace dependency.

Platinum Sponsors

Gold Sponsors

v11.17.0: pnpm 11.17

Compare Source

Minor Changes

• Added a new setting, update.githubActionsServer, for specifying the base URL of the GitHub server that hosts the repositories of the GitHub Actions referenced by the workflow files (for example, a GitHub Enterprise Server). When the setting is not defined, the URL is read from the GITHUB_SERVER_URL environment variable, falling back to https://github.com. The URL must use the https:// or http:// protocol #​13220.

  pnpm outdated and pnpm update no longer fail when the refs of a GitHub Action's repository cannot be read (for example, when the action's repository is private or hosted on a different GitHub server). Such actions are now skipped with a warning.

  Setting update.githubActions to false now makes pnpm outdated and the interactive pnpm update skip GitHub Actions dependencies.

Patch Changes

• The token poll for web-based authentication no longer reads the body of non-OK or still-pending (HTTP 202) responses, and caps the token response body it does read at 64 KiB, so a malicious or compromised registry cannot exhaust memory through the poll pnpm/pnpm#12721.

• Fixed catalog: references in dependencies and overrides failing to resolve when installing through a pnpr server, which errored with "No catalog entry '' was found for catalog 'default'." even though the catalog entry existed. Also fixed a crash on Windows when installing a nested workspace member (e.g. packages/foo) through a pnpr server #​13232.

• Republished every package: the tarballs published by the v11.13.1 through v11.16.0 releases were missing most of their compiled files due to a packing bug #​13164.

• Revert script ordering change for pnpm run --sequential /regex/

• Support the from-git argument in the pnpm version command.

• When the authentication URL cannot be rendered as a QR code (for example when it exceeds the maximum QR data capacity), web-based login now displays the URL alone with a warning instead of aborting authentication pnpm/pnpm#12721.

Platinum Sponsors

Gold Sponsors

v11.16.0: pnpm 11.16

Compare Source

Minor Changes

• The first release of a package now publishes the version written in its manifest verbatim, instead of bumping off it. pnpm version -r and pnpm change status check the registry for each release's current version; when that version is not yet published, the package debuts at it and its pending changesets apply only from the next release. A newly added package seeded at 1100.0.0 with a minor changeset is therefore published as 1100.0.0 rather than skipping straight to 1100.1.0.

• Added a --changeset flag to pnpm update. Set update.changeset to true in pnpm-workspace.yaml to enable this behavior by default, and use --no-changeset to override the setting for one update. After the update completes, pnpm writes a .changeset/pnpm-update-<suffix>.md file declaring a patch bump for every workspace package whose dependencies or optionalDependencies were changed by the update and a major bump when peerDependencies changed, including packages that consume an updated catalog entry via the catalog: protocol. Private packages, packages without a name, and packages listed in the ignore array of .changeset/config.json are skipped. If .changeset/config.json does not exist, a warning is printed and no changeset is generated.

• Added GitHub Actions dependencies to pnpm outdated and interactive pnpm update. Non-interactive updates can include them with --include-github-actions or by setting update.githubActions to true in pnpm-workspace.yaml. Updated actions are pinned to exact commit hashes with their release tags preserved in comments.

• Added update and audit settings sections to pnpm-workspace.yaml, superseding the awkwardly named updateConfig, auditConfig, and top-level auditLevel settings:

  update:
    ignoreDeps: # was updateConfig.ignoreDependencies
      - webpack
      - "@​babel/*"
  
  audit:
    level: high # was auditLevel
    ignore: # was auditConfig.ignoreGhsas
      - GHSA-xxxx-yyyy-zzzz

  update.ignoreDeps lists dependency name patterns that pnpm update and pnpm outdated should skip. audit.level and audit.ignore tune pnpm audit.

  The deprecated updateConfig, auditConfig, and auditLevel settings keep working until the next major version. When both a new section value and its deprecated counterpart are set, the new section takes precedence and a warning is printed. Both the TypeScript CLI and the Rust config surface (pacquet) recognize the new sections.

Patch Changes

• Fixed pnpm add --save-exact/--save-prefix and pnpm update writing a package's version with the peerDependencies range's prefix (e.g. ^19.2.7 instead of the requested 19.2.7) whenever the same package also appeared in peerDependencies. A real dependencies/devDependencies/optionalDependencies entry now takes precedence over a same-named peerDependencies entry when computing the current specifiers #​13108.

Platinum Sponsors

Gold Sponsors

v11.15.1

Compare Source

v11.15.0: pnpm 11.15

Compare Source

Minor Changes

• Optional peer dependencies declared only via peerDependenciesMeta (for example debug's supports-color peer) are now resolved from a satisfying version already present in the dependency graph, the same way explicitly declared optional peer dependencies are. Previously such peers were only resolved this way when the package's metadata was read back from the lockfile, so an unrelated dependency change could rewrite peer resolutions across the whole lockfile.

Patch Changes

• Updated adm-zip to prevent crafted ZIP archives from causing excessive memory allocation.

• pnpm version -r no longer writes a versioning-ledger entry with no consumed intents as a bare intents: key, which the next run failed to read with ERR_PNPM_INVALID_VERSIONING_LEDGER. Empty intent lists are now written as intents: [], and the ledger reader accepts the bare form left by earlier releases.

• Fixed pnpr workspace resolution to preserve project names and versions for workspace: dependencies.

Platinum Sponsors

Gold Sponsors

v11.14.0: pnpm 11.14

Compare Source

Minor Changes

• peerDependencies now accept dependency specifiers that carry a scheme — a named-registry spec (<registry>:<version>), an npm: alias, or a file:/git/URL spec — instead of rejecting them with ERR_PNPM_INVALID_PEER_DEPENDENCY_SPECIFICATION #​13095. Such a peer is matched against the semver range carried by the specifier (work:5.x.x is checked as 5.x.x, npm:bar@^5 as ^5), or against * when it carries no version, while the original specifier still selects the package to auto-install. Bare name@version values, which are almost always a mistake, are still rejected.

• Added pnpm doctor, which diagnoses the pnpm installation and the environment it runs in: the versions and install method, whether the global bin directory is on PATH, whether the store and cache are writable, which link strategies (reflink, hardlink, symlink) the store's filesystem supports, registry connectivity, and an offline file: install that exercises the resolve/store/link path end to end. Each check reports how to fix what it finds, and the command exits non-zero when any check fails.

  Use --offline to skip the checks that need network access, --json for machine-readable output, and --benchmark to time the filesystem and install checks.

• Added support for executing multiple scripts matching a RegExp passed to pnpm run (e.g., pnpm run "/^build:.*/"), running matched scripts in deterministic lexicographical order. Restored the --sequential (-s) CLI option for pnpm run, which forces workspaceConcurrency to 1 so that matched scripts run sequentially one by one across and within packages.

Patch Changes

• Fixed pnpm install failing with ERR_PNPM_LOCKFILE_IS_SYMLINK when pnpm-lock.yaml is a symlink, as build sandboxes such as Bazel and Nix stage it #​13073. Reading a lockfile through a symlink is allowed again, and an install that leaves the lockfile unchanged no longer rewrites it, so --frozen-lockfile no longer needs to write at all. Writing a changed lockfile through a symlink is still refused, as that would redirect the write onto the symlink's target.

• Fixed frozen installs incorrectly treating equivalent Git dependency specifiers as a stale lockfile. See #​13039.

• pnpm owner ls now reports authentication and authorization failures (401/403) as dedicated errors that include the registry's response body, matching pnpm owner add/rm, instead of a generic Failed to fetch owners message.

• Recover from a metadata cache entry that disappears (concurrent cache cleanup, antivirus) after the registry has already answered the conditional request with `304 N

✂ Note

PR body was truncated to here.

---

Configuration

📅 Schedule: (in timezone Asia/Tokyo)

• Branch creation
  • "on monday"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.