Sebastian Poxhofer
4b4d14ec00
* feat(manager): pass extracted constraints to updateArtifacts `extractedConstraints` were collected during extraction but only ever read by `fetch.ts` for the lookup. At artifact time every manager had to derive the same tool constraints a second time, and when the updated package file no longer carried the constraint there was nothing to fall back to. `generateBranchConfig()` now merges the `extractedConstraints` of all upgrades of a branch onto the branch config, which reaches `updateArtifacts()` through `patchConfigForArtifactsUpdate()`. `UpdateArtifactsConfig` declares the field and documents what it contains. The new `resolveToolConstraint()` helper implements the ladder once: user `constraints` > an optional artifact-time derivation > the extracted value. The derivation is ranked above the extracted value on purpose: it reads the package files as the branch changed them, so poetry (python is an updatable dependency there), composer, pipenv (`pipenv` can be a dev package) and pep621 (`requires-python` is an updatable dependency) would otherwise regress to a stale constraint. pipenv, pep621 uv/pdm, poetry and composer are migrated to the helper and keep their derivation. Behaviour change: these managers now use the extract-time constraint as a last resort instead of running unconstrained, for example on lock file maintenance where pipenv deletes `Pipfile.lock` before deriving. `execute-post-upgrade-commands.ts` is unaffected: it reads `upgrade.constraints` per upgrade, and the extracted values are kept in a separate field rather than folded into `constraints`, so post-upgrade task tool constraints still come from user config only. Not migrated, because their constraints are never extracted, so the fallback would be dead code: bundler (`ruby`/`bundler`), pixi (`pixi`), pep621 uv (`required-version`) and npm's node ladder, whose last step already reads `package.json` engines. * refactor(manager): resolve tool constraints through resolveToolConstraint() Every manager now obtains the constraint of a tool it runs through `resolveToolConstraint()` instead of reading `config.constraints` itself, so the precedence "user config, then a value derived from the updated files, then the constraints collected during extraction" applies everywhere. The helper treats an empty string as not set at every step and accepts the `PostUpdateConfig` shape, whose `constraints` may be `null`. Behaviour changes that go beyond the new fallback to extracted constraints: - `mix` applies its hardcoded erlang default only after the extracted constraint, so an erlang version collected at extraction can win over it. - `kustomize` decides `HELM_EXPERIMENTAL_OCI` from the fully resolved helm constraint; `generateHelmEnvs()` takes that value instead of the config. - `npm` (yarn): an upgrade of yarn without a new value now consults the user constraint before deriving one from package.json or the lock file. - The "Using <tool> constraint from config" debug lines in bundler, composer, copier and pip-compile are gone, as the helper is the only reader of the config now. Helpers that read the config synchronously became async: bundler `getBundlerConstraint()`, copier `getPythonVersionConstraint()` and `getCopierVersionConstraint()`, pip-compile `get*VersionConstraint()` and `getToolVersionConstraint()`, gomod `deriveGoToolchainConstraints()` and `getUpdateImportPathCmds()`, mise `getMiseLockToolConstraints()`. composer `getPhpConstraint()` is removed. Each converted manager has a test showing the extracted constraint reaching the executed tool, and, where a derive callback exists, that the derived value still wins over it. * refactor(linters): add prefer-resolve-tool-constraint rule Reports member reads and destructuring of `constraints` and `extractedConstraints` from a manager config in `lib/modules/manager/**`, so that tool constraints are resolved through `resolveToolConstraint()` in `lib/modules/manager/util.ts` only. Writes and the same properties on package files, which extraction has to populate, are not reported. The helper itself and spec files are exempt in `.oxlintrc.json`. * refactor(manager): inline thin resolveToolConstraint wrappers Drop copier/utils.ts and the pip-compile getPipToolsVersionConstraint / getUvVersionConstraint helpers, which only forwarded to resolveToolConstraint(). Callers now call it directly. * docs(development): note lock file maintenance in tool constraints section * refactor(manager): address review on tool constraint resolution composer only runs extractConstraints() when a user constraint is missing, via Lazy. UpdateArtifactsConfig no longer re-declares constraints and extractedConstraints, which ToolConstraintsConfig already provides.
What is the Mend Renovate CLI?
Renovate is an automated dependency update tool. It helps to update dependencies in your code without needing to do it manually. When Renovate runs on your repo, it looks for references to dependencies (both public and private) and, if there are newer versions available, Renovate can create pull requests to update your versions automatically.
Features
- Delivers update PRs directly to your repo
- Relevant package files are discovered automatically
- Pull Requests automatically generated in your repo
- Provides useful information to help you decide which updates to accept (age, adoption, pass rates, merge confidence)
- Highly configurable and flexible to fit in with your needs and repository standards
- Largest collection of languages and platforms (listed below)
- Connects with private repositories and package registries
Languages
Renovate can provide updates for most popular languages, platforms, and registries including: npm, Java, Python, .NET, Scala, Ruby, Go, Docker and more. Supports over 90 different package managers.
Platforms
Renovate updates code repositories on the following platforms: GitHub, GitLab, Bitbucket, Azure DevOps, AWS Code Commit (experimental), Gitea, Forgejo, Gerrit (experimental), SCM-Manager (experimental)
Ways to run Renovate
The most effective way to run Renovate is to use an automated job scheduling system that regularly runs Renovate on all enabled repositories and responds with priority to user activity. Mend offers cloud-hosted and self-hosted solutions. See the options below.
Mend Renovate Community (Cloud-Hosted)
Supports: GitHub.com, Bitbucket Cloud
Hosted by Mend.io. No setup is needed. Community plan available (Free)
- GitHub Cloud: Install the Renovate Cloud-Hosted App on your GitHub org, then select the repos to enable
- Bitbucket Cloud: Add the Mend App to your Workspace, then add the Mend Renovate user to the projects you want to enable
Mend Renovate Community (Self-hosted)
Supports: GitHub, GitLab, Bitbucket Data Center
Install and run your own Renovate server. Access internal packages.
- Mend Renovate Community Self-Hosted (Free)
- Mend Renovate Enterprise (Paid plan)
Other ways to run Renovate
If you can’t use a pre-built job scheduling system, or want to build your own, the following options are available:
Run Renovate on your Pipeline
Mend provides a GitHub Action or a GitLab Runner to help you run Renovate as a CI pipeline job.
- GitHub Action: renovatebot/github-action.
- GitLab Runner: Renovate Runner project
- AzureDevOps action: Renovate Me extension
Note: This extension is created and maintained personally by a Renovate developer/user. Support requests for the extension will not be answered directly in the main Renovate repository. - Custom pipeline: You can create a custom pipeline with a yml definition that triggers npx renovate. More details on how to configure the pipeline.
Run Renovate CLI
There are several ways to run the Renovate CLI directly. See docs: Running Renovate for all options.
Supports: all platforms
For additional community-maintained options, see the Community Tools page.
Docs
More about Renovate
- Renovate basics
- Supported platforms and languages
- Advanced Renovate usage
Renovate Docs
Comparisons
Get involved
Issues and Discussions
Please open a Discussion to get help, suggest a new feature, or to report a bug. We only want maintainers to open Issues.
Contributing
To contribute to Renovate, or run a local copy, please read the contributing guidelines.
- Guidelines for Contributing
- Items that need contribution: good first issues
Contact and Social Media
The Renovate project is proudly supported and actively maintained by Mend.io.
- Contact Mend.io for commercial support questions.
Follow us on:
- Twitter: x.com/mend_io
- LinkedIn: linkedin.com/company/mend-io
Security / Disclosure
If you find any bug with Renovate that may be a security problem, please report it through the GitHub Security Advisories process. This way we can evaluate the bug and hopefully fix it before it gets abused. Please give us enough time to investigate the bug before you report it anywhere else.
If you would like to discuss a potential finding before raising the Advisory, then e-mail us at: renovate-disclosure@mend.io.