* 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>
* 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>
* 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.
* chore(types): add a strong type for `ToolName`s
Until #41849, we can use our local definitions of the tool names that
Containerbase supports by extracting out a `ToolName` type.
* fixup! chore(types): add a strong type for `ToolName`s
Co-authored-by: Claude Opus 4.6 <jamie.tanna+claude-code@mend.io>
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
* fixup! fixup! chore(types): add a strong type for `ToolName`s
* no-never
* simplify
* coverage
* sq
* warn
* sq
* fixup! sq
* sq
* fixup! sq
---------
Co-authored-by: Claude Opus 4.6 <jamie.tanna+claude-code@mend.io>
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
Without this, the Maven data source throws out all candidates in postprocessRelease as it cannot find the
releases by version which is not the original version anymore unless als extractVersion was used
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
Moves datasource, manager, platform and versioning code from lib/ into new lib/modules/
BREAKING CHANGE: External tools must update paths to datasource, manager, platform and versioning
Michael Kriese