* ci(linter): add renovate/require-regex-util rule Adds a custom oxlint rule that flags raw RegExp usage in lib/ production code: any `new RegExp(...)` call and any regex literal that is not the direct first argument of `regEx(...)`. The regEx() helper from lib/util/regex.ts uses the RE2 engine for ReDoS-safe matching and caches compiled patterns. lib/util/regex.ts itself is exempt. The rule is disabled for **/*.spec.ts, test/**, and tools/** via config overrides, because vitest APIs such as expect.stringMatching need bare RegExp instances (a past commit reverted regEx() there). Severity is set to "warn" instead of "error": the repo currently has 197 pre-existing violations (above the agreed mechanical-fix threshold of 80), and a number of them are deliberately RE2-incompatible patterns (lookahead/lookbehind/named backreferences, see TODO #12872/#12875 markers in e.g. lib/modules/versioning/rez/ pattern.ts and lib/modules/manager/dockerfile/extract.ts) that need per-site judgment before they can be wrapped in regEx() or suppressed with a justified disable comment. No violation fixes are included in this commit. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * ci(linter): enforce renovate/require-regex-util at error Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor: use regEx() for regex literals and RegExp construction in lib Burn down all renovate/require-regex-util violations (197): - wrap RE2-compatible regex literals and RegExp constructions in regEx() - rewrite lookaround patterns where behavior is provably preserved: goproxy separator split, sbt-package link extraction, leiningen comment stripping and keyword search, npm GitHub owner validation (unit-count bound replaced by an explicit length check) - keep native RegExp with disable comments where RE2 cannot be used: moo / good-enough-parser lexer patterns (moo rejects RE2 instances), MigrationsService propertyName (matched via isRegExp, which RE2 instances fail), rez named backreferences and lookaheads, GitHub markdown link negative lookbehind, emoji astral-plane matching - drop stale TODO #12875 comments for patterns current re2 handles Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor: reduce require-regex-util disable comments Rewrite the github massage-markdown-links URL regex to capture an optional `api.` prefix in a named group (skipped in code) instead of relying on a negative lookbehind, so both the base and global variants can use regEx()/RE2 and their two disable comments are removed. Add spec cases for api-prefixed URLs that match the URL shape. Consolidate the four related line disables in rez/pattern.ts (bound and range patterns emulating Python conditional patterns via named backreferences and lookaheads, which RE2 cannot express) into a single block disable/enable pair, matching the treatment of the lexer files. Disable comment count drops from 13 to 8. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor(datasource/sbt-package): use named capture group in link regex Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor(manager/cake): restore original multiLineComment regex spelling The [^] -> [\\s\\S] rewrite was only needed for an RE2 wrap that was later reverted; keep the diff minimal. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(datasource/go): skip empty GOPROXY segments The switch from a lookahead split to a capture-group split (needed because RE2 has no lookahead support) changed how empty GOPROXY segments parse: `a|,b` yielded `{ url: ',', fallback: '|' }` before and `{ url: '', fallback: ',' }` after. The comma fallback only continues on 404/410, so a failing proxy ahead of an empty segment silently stopped the lookup instead of falling through to the remaining proxies. Empty segments carry no url to query, so drop them. * refactor(datasource/go): use isTruthy for empty segment filter * fix(datasource/go): filter empty segments before mapping Filtering after the map broke the contextual typing from the GoproxyItem[] annotation, widening fallback to string. * refactor(platform/github): use regEx() for merge queue query stripping --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
This manager parses Flux YAML manifests and supports:
HelmReleaseresourcesGitRepositoryresourcesOCIRepositoryresources- Flux system manifests
HelmRelease support
Extracts helm dependencies from HelmRelease resources.
The flux manager extracts helm dependencies for HelmRelease resources linked to HelmRepository or GitRepository sources.
HelmRepository resources can be referenced via spec.chart or indirectly via a HelmChart when
using spec.chartRef.
Renovate supports OCI HelmRepository sources, those with type: oci.
Renovate will then extract the docker dependencies for the referenced HelmRelease resources.
In addition, for the flux manager to properly link HelmRelease and HelmRepository resources, both of the following conditions must be met:
- The
HelmReleaseresource must either have itsmetadata.namespaceproperty set or itsspec.chart.spec.sourceRef.namespaceproperty (when not usingchartRef) set - The referenced
HelmRepositoryandHelmChart(when usingchartRef) resources must have theirmetadata.namespaceproperty set
Namespaces will not be inferred from the context (e.g. from the parent Kustomization).
Renovate updates HelmRelease resources coming from GitRepository by updating the GitRepository resource.
Renovate updates Docker dependencies inside HelmRelease values like the helm-values manager.
When a referenced HelmRepository resource is not present in the scanned manifests (for example, it is defined in another repository or as a cluster-global resource), you can statically map the sourceRef.name of the HelmRelease (or HelmChart) to a registry URL using registryAliases in your flux configuration:
{
"packageRules": [
{
"matchManagers": ["flux"],
"matchDatasources": ["helm"],
"registryAliases": {
"podinfo-repo": "https://stefanprodan.github.io/podinfo"
}
}
]
}
In this example, a HelmRelease whose spec.chart.spec.sourceRef.name is podinfo-repo will be treated as if it were backed by a HelmRepository with URL https://stefanprodan.github.io/podinfo.
GitRepository support
Renovate can update git references from GitRepository resources.
The flux manager only updates GitRepository fields that have a tag or commit key.
When commit is being updated, if a branch key is also present, only commits from that branch will be considered.
Kustomization support
Renovate can update image1 references from Kustomization resources.
OCIRepository support
Renovate can update oci references from OCIRepository resources.
The flux manager updates OCIRepository fields that have a digest, tag or both keys.
Flux system manifests support
Renovate supports updating Flux system manifests generated during Flux installation.
System manifests are identified via being named gotk-components.y(a)ml and containing comment headers as generated by flux bootstrap.
!!! warning
Renovate cannot identify the use of custom bootstrap flags, such as --cluster-domain.
In such a scenario Renovate's PR will overwrite these values with the Flux defaults.
See issue #13952 on GitHub for more information.
Updating system manifests requires that either:
- The
fluxtool is pre-installed, or - You run a Docker image based on containerbase, such as the official Renovate images, and have
binarySource=installconfigured
Default managerFilePatterns
By default, the flux manager only matches **/gotk-components.y(a)ml.
So it only checks system manifest files generated by the flux bootstrap command.
This is because there is no commonly accepted file/directory naming convention for Flux manifests and we don't want to check every single *.yaml file in repositories just in case some of them have Flux definitions.
If most .yaml files in your repository are Flux manifests, then you could add this to your config:
{
"flux": {
"managerFilePatterns": ["/\\.yaml$/"]
}
}
If instead you have all your Flux manifests inside a flux/ directory, you would add this:
{
"flux": {
"managerFilePatterns": ["/flux/.+\\.yaml$/"]
}
}
Versioning
If you need to change the versioning format, read the versioning documentation to learn more.