* feat(datasource/go): conditionally expose `constraints`
As noted in #42567, some Go modules are constrained by their
compatibility with the source compatibility with the Go language as per
the `go` directive.
Bumping the `go` directive will result in all of a library's consumers
also needing to bump their own `go`, which can be something library
authors will attempt to avoid.
Previously, Renovate users would receive an update from any modules that
have a new release, regardless of whether they will bump the `go`
directive.
With this change, users who use `constraintsFiltering=strict` will have
the filtering applied, so they only receive updates for Go modules in
their current minor version.
Due to the additional API calls needed, this is an opt-in feature, and
only includes the API calls when the using
`constraintsFiltering=strict`.
We can also add an integration test to build our confidence in the
end-to-end flow.
* fix(datasource/go): correctly check Go directive for major version bumps
As we weren't passing around the `pkg` (which included the Semantic
Module Import Path), we were incorrectly lacking major version upgrades.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* chore: remove `fallback`
As it's unnecessary.
* docs(gomod): rephrase
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
As part of future changes in #42567 to surface the `constraints` of a
given Go module, we should first extract the constraints from the
package file.
To make this simpler for users, we can make sure we extract these at
parse time:
- the `toolchain` directive becomes the `golang` constraint, which
matches the `golang` tool name already in use for Containerbase
- the `go` directive becomes a new `%goMod` constraint, which keeps it
separate from the version of the Go toolchain actually used to run, as
well as clearly not for the Go tooling, or something that
Containerbase knows about
- we make sure to extract it with a SemVer range that can then be used
to ensure that, in future changes, using `constraintsFiltering=strict`
will allow filtering releases from the Go datasource based on this
constraint.
- because we're now returning the `constraintsVersioning`, we need to
make sure this is part of our types
* feat: allow separate versioning for constraints
As noted in #31831, there are times where it can be useful to override
the version that a given datasource uses, when performing
`constraintsFiltering=strict.`
This should only be applicable to the "additional" constraints, so we
make sure to validate this.
As this is new functionality, any misconfiguration should be marked as
an error.
We can make sure to provide a real-world usecase for this (taking
inspiration from `rails`' versioning of the `rubygems` constraint).
This will be used in the future by the extraction of the `go` directive,
which requires a different versioning to the default `semver`.
* fixup! feat: allow separate versioning for constraints
* fixup! feat: allow separate versioning for constraints
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* extra-log-context
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* feat(terraform): add OCI protocol support for modules and providers
Adds support for Terraform modules and providers hosted in OCI-compatible
container registries using the `oci://` protocol.
Delegates OCI sources to Docker datasource for version resolution.
Supports both version in separate field and embedded in URL.
Closes https://github.com/renovatebot/renovate/discussions/38927
* refactor(terraform): address code review feedback for OCI support
cd - Move ociRefMatchRegex to shared location in base.ts
cd - Extract OCI parsing into parseOciRef function to reduce duplication
cd - Remove unnecessary registryUrls assignments
cd - Add skipReason when OCI tag is unspecified
cd - Inline oci.tf fixture to avoid triggering vulnerability scanners
cd - Refactor OCI regex tests to use it.each
* refactor(terraform): address PR review, round 2
- Replace custom ociRefMatchRegex/parseOciRef with getDep pattern,
reusing isOCIRegistry/removeOCIPrefix from helmv3/oci.ts
- Remove docs/development/oci-terraform-support.md
- Remove ociRefMatchRegex/parseOciRef from base.ts and modules.ts
- Simplify OCI test in extract.spec.ts
- Remove ociRefMatchRegex describe block from modules.spec.ts
* refactor(terraform): address PR review, round 3
extract duplicate function
Signed-off-by: Norman Stetter <85173861+norman-zon@users.noreply.github.com>
* fix: only allow valid oci urls
oci sources only support query params for versioning
* feat: pass through registryaliases
* fix: fix broken tests
* fix: address PR review round 4
* fix: replace new URL with parseUrl
Signed-off-by: Norman Stetter <85173861+norman-zon@users.noreply.github.com>
* fix: add tests for new path
Signed-off-by: Norman Stetter <85173861+norman-zon@users.noreply.github.com>
---------
Signed-off-by: Norman Stetter <85173861+norman-zon@users.noreply.github.com>
* feat: use poetry deps to enrich equivalent pep621/pep735 deps
* test: cover project.optional-dependencies in enrichment test
* refactor: replace reduce usage with for..of loop
* refactor: use nullish-coalescing during variable assignment
* refactor: use coerceArray helper instead of nullish coalescing
* fix(validation): validate `constraints`
To provide better coverage for our users of what is a valid option for a
`constraints` value, we can validate the overall format of the
`constraints` block, as well as the given names of constraints.
Where we have a Tool defined, we can use the default versioning for that
Tool to validate the constraint's value.
For now, both the validation of the `constraints`' value, and the
validation of `constraints`' names will be a warning, but in the future
may be made an error.
* chore(validation): remove check for `compatibility`
As this was renamed in #7308. It's been long enough since then that we
can remove this check.
* chore(validation): add logger in `else` case
For coverage fix, and also to provide insight when this does happen
* fixup! chore(validation): add logger in `else` case
* fixup! chore(validation): add logger in `else` case
* key
* coverage
* Remove duplicate function
As it's been pulled in via another PR.
* fixup! docs(constraints): document the possible `constraints` and `installTools` (#42837)
As it can't be `undefined`.
* test: coverage
And more whitespace to make it clearer they're two separate `if` blocks.
* typo
* typo
---------
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
* feat(mise): automagically support all tools through Mise Registry
As noted in #42250, we should try and auto-support tools from Mise where
possible.
Similar to other areas of the codebase, we should use the "static data"
pattern, and periodically sync the `mise registry --json` output with
`lib/data/mise-registry.json`, and then auto-detect the tools that we
support through the known backends the tools support.
This takes lower precedence than existing in-code tool definitions, so
we can still provide an "override" if we can support lookups or version
extraction more appropriately.
Because we now have many more tools we (mostly) support out-of-the-box,
we need to provide an improved documentation page, and:
- only link to tools we have an explicit tools URL for
- note where a backend may not be supported
To automate the updating of this data, we:
- make sure we have `mise` in GitHub Actions, before we run
- don't pin the `mise` version to make sure that we're always seeing the
latest supported tools
- make sure the commits generated are now `feat(...)`, as they introduce
functionality changes (in the case new tool(s) are supported)
This improves support from ~170 tool short names to just over 1000.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* refactor: use Typescript
As we can now, we should.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* refactor(tools/static-data): use Zod schemas for parsing
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* refactor(mise): use Zod for types
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* chore(mise): prefer the GitHub backend over other sources
As we generally prefer it as a project, we should automagically use that
when looking at a mise registry entry.
With help from GPT-4.1 to write the `sortBackend` function.
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
* test: ignore else coverage
* docs(mise): preference of `github` backend
* docs(mise): auto-link autogenerated tools
* perf(mise): sort registry only once
* refactor(mise): transform when parsing
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
* refactor: use `execa`
* perf(mise): read the Mise registry once
* perf(mise): pre-transform
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
* fix(gerrit): defer change creation to `createPr()`
Signed-off-by: Felipe Santos <felipe.santos@ericsson.com>
* Refactor hashtags handling
* Add prTitle to all missing commitAndPush()
* Fix gerrit tests
* Add warning when prTitle is set in updatePr
* Remove now useless labels from commitAndPush
* Fix gerrit client coverage
* Fix gerrit scm coverage
* Fix rebase coverage
* Improve TODO about assignees
* Fix formatting
* Fix review comment
* Extract to a pushForReview function
* Fix after #41382
* Fix onboarding
* Cleanup code
* Fix ESLint
* Fix tests
* Restore gitRetry for git.merge
* Fix tests
* Simplify hashtags code
* Delete pendingChangeBranch in pushForReview()
* Fix test name
* Remove unnecessary test comments
* Improve test name again
* Fix another test name
* Delete local branch in Gerrit SCM
* Add test for deleting pending branch
* Add tests for pushForReview()
* Fix test case name
* Improve another test name
* Fix another small test inconsistency
* Fix some code style issues
* Use isUndefined instead
* Fix one small test style issue
---------
Signed-off-by: Felipe Santos <felipe.santos@ericsson.com>
As part of future changes, we'll introduce additional constraints that
may take priority, so we should ensure we have coverage of the existing
logic.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* feat(manager): add proto manager for .prototools files
Add a new manager for moonrepo's proto tool version manager.
Proto uses .prototools (TOML) files to pin tool versions at the
directory level. The manager extracts top-level version entries
and maps them to the appropriate Renovate datasources.
Supported built-in tools: bun, deno, go, moon, node, npm, pnpm,
yarn, python, ruby, rust, proto, gh, poetry, uv.
Non-version sections ([settings], [plugins], [tools], [env],
[shell], [backends]) are correctly ignored. Version aliases
(latest, stable, canary, nightly) are skipped with appropriate
skipReason. Unknown tools are reported as unsupported-datasource.
* fix(manager): address proto manager PR review feedback
- Remove deduplicateArray/sort from supportedDatasources, sort manually
- Sort protoTooling entries alphabetically
- Inline createDependency call into deps.push()
- Inline fixture content into test, remove fixture file
* feat(terraform-provider): add zod schemas for v2 API response
* feat(terraform-provider): use registry v2 API for release timestamps
* feat(terraform-provider): add zod schema for OpenTofu API response
* feat(terraform-provider): add OpenTofu registry docs API support
* feat(terraform-provider): update v2 API response handling and schema validation
* feat(terraform-provider): use schema transform for OpenTofu response
* fix(terraform-provider): address PR review feedback for OpenTofu support
* fix(terraform-provider): resolve sourceUrl from OpenTofu version details
* fix(terraform-provider): derive OpenTofu sourceUrl from registry naming policy
As noted in #42519, the preivous commit/PR title wasn't quite as clear
with what was actually changing.
To make this more explicit, we can override `commitMessageTopic`.
* feat(datasource/npm): extract defaultRegistryUrl constant
* Fix some other places
* Remove useless defaultRegistryUrls export
* Fix another place
* Undo rules.spec.ts changes, which are not related
* Fix npm presets
* Restore line removed by mistake
* Fix another test file
* Restore changes to a file which is not relevant
* Fix another small place
* chore(datasource): add missing parentheses
* fix(datasource): handle both config and release constraints as a range
In the case that the user's config is a range, but the release itself
provides an exact value for the constraint, we currently do not
correctly filter it.
* chore(datasource): add trace logging for `applyConstraintsFiltering`
As a way to provide more additional information to users who are
debugging when `constraintsFiltering=strict`, we can add some TRACE
logs.
We can use the prefix `applyConstraintsFiltering` for all log lines, so
we can use `logLevelRemap` more easily.
* test(datasource): add coverage
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
When we truncate the PR body (due to platform limits) we should be
clearer as to where this was trimmed.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fix(manager/flux): extract both tag and digest for OCIRepository
Signed-off-by: Robin Schneider <mail@robinschneider.dev>
* Use record instead of map
Signed-off-by: Robin Schneider <mail@robinschneider.dev>
* Avoid state duplication
Signed-off-by: Robin Schneider <mail@robinschneider.dev>
* Adjust regex
Signed-off-by: Robin Schneider <mail@robinschneider.dev>
* Adjust fallback
Signed-off-by: Robin Schneider <mail@robinschneider.dev>
* test(manager/flux): cover missing-header system manifest branch in extractAllPackageFiles
* fix(manager/flux): update both tag and digest for OCIRepository refs without regex
* test(manager/flux): cover extractOCIRefRange guard branches
* test(manager/flux): cover remaining extractOCIRefRange branches
---------
Signed-off-by: Robin Schneider <mail@robinschneider.dev>
As noted in #42899, some Actions use a version such as `v2.2-rc.1` which
we weren't handling or updating.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* test(versioning/maven): increase test coverage
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* test(versioning/maven): add examples for Jenkins-style version constraints
For future related changes, it would be good to have a test covering
exact syntax needed.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* docs(constraints): list the possible `constraints` and `installTools`
Now we have a stronger type for what a valid tool constraint is, and
what additional constraints are, we should be very explicit with what
each option is, and specify them in the `constraints` as well as our
`installTools` docs.
* test: add coverage
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
Instead of inline documentation with JSDoc, we can use an optional
`description` field that can be accessed programatically.
This means the `description` can also be added to our JSON Schema for a
Tool, or be the only output when a non-Tool constraint, as the
description for non-Tools are more clear than the autogenerated text.
We can make sure we continue to export the known names, as well as the
full definitions.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
In a similar fix to 06cf949974, this fixes
early versions of `https://registry.npmjs.org/fs-extra` returning an
array value for `homepage`, resulting in no caching for these responses.
* chore(workers/repository): provide more detail when rolling back
To help debug the case where rollbacks are being initiated, we can:
- add slightly more information to the `Filtered out ...` log line
- add `prBodyNotes` to the resulting PR
This requires we expose the `prBodyNotes` field to `LookupUpdate`, and
the `packageName` and `datasource` to `RollbackConfig`, so we can log
them.
* chore(modules/datasource): log `datasource` and `packageName` when filtering
For more context when reviewing the logs.
Jamie Tanna