As part of changes towards #46438, it was noticed that there wasn't
coverage for the ability to specify `constraints` inside `packageRules`.
Co-authored-by: Claude Opus 5.5 <jamie.tanna+claude-code@mend.io>
* fix(manager/gomod): allow modules with an older `go` directive
As noted in #47313, when using `constraintsFiltering=strict`, any Go
modules which declare a `go` directive on an /older/ minor version than
the repository's are filtered out, even though they would not require
bumping the repository's `go` directive.
This seems to have been documented as the intent in
0e5e384237 - hence the test added to note
the behaviour - but this leads to us not updating versions we should do.
We can instead convert it into the range `<=1.26.x`, which allows the
same or older minor versions, and continues to filter out newer ones,
which applies with the `semver-coerced` versioning scheme.
Co-authored-by: Claude Opus 5.5 <jamie.tanna+amp@mend.io>
* fixup! fix(manager/gomod): allow modules with an older `go` directive
---------
Co-authored-by: Claude Opus 5.5 <jamie.tanna+amp@mend.io>
As noted in #47311, when an option is used somewhere it can't be, the
warning only names the type of object it was found in, i.e.
> "hostRules" can't be used in "packageRules", as it can only be used
> at the top level of a config.
This isn't ideal when there are many `packageRules` or `customManagers`,
so we should improve this to include an index (`packageRules[53]`), and
the `customType` (`custom.regex[25]`) or the nested parent
(`npm.minor`).
Co-authored-by: Claude Opus 5.5 <jamie.tanna+amp@mend.io>
As noted in #47311, the `description` option - which can be used
anywhere - was being flagged as invalid inside the `regex` custom
manager config, with the confusing message:
> "description" can't be used in "regex", as it can only be used
> anywhere in a config.
A separate change fixes that specific case, but more generally, if we
have an `any` scope, that should be allowed regardless, and we should
skip the check for where it's used.
We still expand the `any` scope to its parents, as that's needed to
generate the JSON Schema and the default config.
To test this in a case that provides us confidence - given we don't
currently have any options that are mislabeled, we need to mock the
import, which seems a bit hacky, but works.
Co-authored-by: Claude Opus 5.5 <jamie.tanna+amp@mend.io>
As noted in #47311, when we added validation for what parent an option
could be used with, if you configured a Manager-specific config for a
Custom Manager i.e.
```json
{
"regex": {
"ignorePaths": []
}
}
```
this would now raises a warning that `ignorePaths` can't be used in
`regex`, even though at runtime, we would merge this config in. same as
any other manager.
We can add the missing Custom Manager names to the known managers
allowed at top-level.
Co-authored-by: Claude Opus 5.5 <jamie.tanna+amp@mend.io>
As noted in [0], the stricter validation we now perform with
`allowedValues` has provided a little too-strict validation with
`matchUpdateTypes`, which is matched as a regex or glob.
If we don't treat them as a pattern, we see i.e.:
Invalid packageRules[2].matchUpdateTypes: matchUpdateTypes had
invalid values `["!major"]` which are not part of the allowedValues
For options with `patternMatch` set, we can instead treat a value as
valid if it can match any of the `allowedValues`, once any leading `!`
has been removed. This still catches typos such as `!majr`.
Currently `matchUpdateTypes` is the only option with both `allowedValues`
and `patternMatch`, but this will apply to any future options.
Co-authored-by: Claude Sonnet 5.5 <jamie.tanna+claude-code@mend.io>
[0]: https://github.com/renovatebot/renovate/pull/39076#issuecomment-6334467901
As noted in #47292, since `gh actions-lock` v0.2.0 locked pins are
sticky: running `gh actions-lock` only resolves refs that the lockfile
doesn't record yet.
If a ref updates (i.e. `pnpm/setup@v3.0.0` to `pnpm/setup@v3.1.1`), then
`gh actions-lock` fails with a `Ref changed` error and `Unused lockfile
entry`, and writes nothing out, leaving the branch in an unusable state.
Per v0.2.0's release notes, we should use `--relock` to re-resolve every
ref and rebuilds the lockfile graph.
This updates floating tags i.e. `@v4` when occurring, because they are
technically a floating tag that has now updated.
Co-authored-by: Claude Sonnet 5.5 <jamie.tanna+claude-code@mend.io>
As noted in #47266, we had missed the case that an inherited config's
`onboardingConfig` now leads to config validation warnings.
There is special handling in global and repo config, but this was missed
for inherited config.
Co-authored-by: Claude Sonnet 5.5 <jamie.tanna+claude-code@mend.io>
When a GitHub Actions Workflow digest pins against a repository that
tags releases with the `v` prefix, but the Workflow itself doesn't use
the `v` like:
uses: renovatebot/github-action@abd08c7549 # 46.1.5
we correctly match `46.1.5` to the release `v46.1.5` and propose an
update, but when we do a `digest` update (which confirms whether the
current digest SHA is still what the tag is pointing to) it uses
`46.1.5` as its `newValue`.
We look for a release with that version verbatim, and because it's
missing the `v` prefix, we'll perform a failed tag lookup:
DEBUG: github/tags.findCommitOfTag: Tag 46.1.5 not found for renovatebot/github-action
DEBUG: Could not determine new digest for update.
As we have a `currentDigest`, this also adds a warning for the
dependency, and we'll never be able to update if the underlying tag has
moved, because we can't look up the tag's SHA.
Although we could retry the lookup with the `v` prefix, we should
instead treat this as the misconfiguration it is, and surface it more
visibly to users with a WARN log.
If we did provide a retry, this could lead to a supply chain attack
where a repository maintainer could push both a `1.2.3` and `v1.2.3` and
convince Renovate to update to a malicious version.
Co-authored-by: Claude Sonnet 5.5 <jamie.tanna+claude-code@mend.io>
Instead of using custom logic to validate the `customDatasources`, we
can instead validate them using our existing validation logic.
This makes sure that `format` is part of its `allowedValues`, and
`defaultRegistryUrlTemplate` and `transformTemplates` are valid
templates.
Via review of the validation code by Claude Fable 5.1.
Co-authored-by: Claude Sonnet 5.5 <jamie.tanna+claude-code@mend.io>
As we hadn't previously documented that all of the formats were valid,
which leads to JSON schema not suggesting the options.
We don't (yet) perform config validation, but will do in the future,
which we need to know all valid options for.
Co-authored-by: Claude Sonnet 5.5 <jamie.tanna+claude-code@mend.io>
As `validateConfig` expects massaged config, we should massage the
static repo config before we validate it, as we do for the resolved
repository config.
Otherwise, a string for an option which allows a string (i.e.
`description: "static"`) is reported as invalid, which then logs a
validation issue that the user can't do anything about.
We only massage the config for validation, so the config that is
returned is unchanged.
Via review of the validation code by Claude Fable 5.1.
Co-authored-by: Claude Sonnet 5.5 <jamie.tanna+claude-code@mend.io>
As `validateConfig` expects massaged config, we should massage the
inherited config - both as it's read, and once its presets have been
resolved - before we validate it, as we do for the repository config.
Otherwise, a string for an option which allows a string (i.e.
`description: "shared"`) is reported as invalid, which fails the run.
We only massage the config for validation, so the config that is merged
is unchanged.
Via review of the validation code by Claude Fable 5.1.
Co-authored-by: Claude Sonnet 5.5 <jamie.tanna+claude-code@mend.io>
As part of follow-up changes, we'll fix this, but should have existing
test coverage first.
`validateConfig` expects massaged config (i.e. where an option that
`allowString`s has had its string converted to a list), but neither the
inherited config nor the static repo config are massaged before being
validated.
This means that a string for an option which allows a string, such as
`description: "shared"`, is reported as `should be a list (Array)`.
For an inherited config that leads to a failed Renovate run, and for a
static repo config it logs a validation issue that the user can't do
anything about.
In practice, this doesn't seem to impact too many users, but we should
make sure that this is stricter.
Co-authored-by: Claude Sonnet 5.5 <jamie.tanna+claude-code@mend.io>
To make sure that we provide feedback when an option which is a list of
strings (`subType: 'string'`) contains an entry that isn't a string,
i.e. `schedule: [1]`, or `transformTemplates: [{}]`, as we previously
only checked that the value was an array.
Some options (`extends` and `commitTrailers`) already report their
invalid entries with a more specific message, so we skip those.
As we now check the entries of `mergeConfidenceDatasources` in the same
way, the `[1]` in its test is now reported, which had been reported by
a (since removed) custom check.
Via review of the validation code by Claude Fable 5.1.
Co-authored-by: Claude Sonnet 5.5 <jamie.tanna+claude-code@mend.io>
Instead of using custom code to handle this for a subset of options, we
can instead make sure that we're using the shared
`validateAllowedValues` function.
Although this does reduce some of the more human-readable custom worded
messages, this keeps things more consistent and scalable as options are
added.
This also removes the checks for `enabledManagers` ("not supported")
and `customType` ("is not a custom manager"), which are now reported
twice: once by the shared function, and once by the custom check.
Via review of the validation code by Claude Fable 5.1.
Co-authored-by: Claude Sonnet 5.5 <jamie.tanna+claude-code@mend.io>
To make sure that we provide faster feedback for users, we should
validate that for options that have an `allowedValues` set, we validate
the option according to the value.
We also need to:
- handle a single option value
- handle an array of option values
- handle when a default (`null`) option is used, as that won't match
`allowedValues`
- handle when a `supportsTemplating` config option is used alongside
`allowedValues`, but only skip validating the value when it contains
`{{`, as that's when it's templated. Otherwise it can be validated as
any other value
- add a special case to handle `packageRule.versioning` differently, as
it may have a `regex:` value which isn't technically in the
`allowedValues`
For options with a large number of `allowedValues` (i.e.
`enabledManagers` or `postUpdateOptions`), listing all of them makes for
an unreadable message, so we link to the documentation instead.
This adds a number of extra errors for some validation that is already
happening for specific options' values, which we'll follow-up and remove
the duplication for.
This also makes sure that we validate this for both repository config
and global config, which means an invalid `reportType` is now reported.
Via review of the validation code by Claude Fable 5.1.
Co-authored-by: Claude Sonnet 5.5 <jamie.tanna+claude-code@mend.io>
We don't currently check that the option's value is an array of strings,
which leads to i.e.
Uncaught TypeError: "nope".filter is not a function
Via review of the validation code by Claude Fable 5.1, which fuzzed
every option with values of the wrong type, and found only these two
options throw.
Co-authored-by: Claude Sonnet 5.5 <jamie.tanna+claude-code@mend.io>
renovate[bot]