renovate

mirror of https://github.com/renovatebot/renovate.git synced 2026-10-25 23:11:31 +00:00

Files

T

Jamie Tanna 2d239d2cc1 docs: explicitly document depTypes each manager supports (#42142 )

* docs: explicitly document `depTypes` each manager supports

A long-standing question we receive is "what `depTypes` can I match
against in my project".

Although the best recommendation we usually have is "check the
`packageFiles with updates" log line (as a very key log line for users),
we can go one step further and try and create a stronger contract.

To do this, I've used Claude Sonnet 4.6 to work through the codebase,
determine areas that a `depType` is set in a manager (statically or
dynamically) and generate a structured, typed, means to document how
they're used.

Through a few iterations of the process, and attempts at human-written
documentation, we've settled on:

- prioritising autogenerated documentation (for humans to read) to note
  what `depTypes` are known, and what they are
- `knownDepTypes`, to describe any known, static, `depType`s and their
  human-readable meaning
  - with the `prettyDepType`, if used
- `supportsDynamicDepTypesNote`, to add a Markdown note to the generated
  documentation

While here, we also:

- make sure to note this in the "adding a new package manager"
  documentation
- remove any hand-written references to `depTypes` in each manager's
  documentation page
- correct the Gleam `depTypes`
- make sure to use the `knownDepTypes`'s `prettyDepType` definition if
  we know it, for a given `depType`

The descriptions have been generated by Claude Sonnet, with some
human-written tweaks where appropriate.

[0]: https://github.com/renovatebot/renovate/discussions/15176

Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>

* fixup! docs: explicitly document `depTypes` each manager supports

* docs(manager): display `depTypes` documentation if none present

For consistency, and to make it more explicit.

---------

Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>

2026-03-31 12:08:39 +00:00

artifacts.spec.ts

feat(sidecar): use renovatebot/base-image instead of containerbase/sidecar (#40772 )

2026-01-29 10:05:24 +00:00

artifacts.ts

refactor: Rewrite imports with .ts extensions (#40700 )

2026-01-26 22:48:17 +00:00

common.spec.ts

refactor: Rewrite imports with .ts extensions (#40700 )

2026-01-26 22:48:17 +00:00

common.ts

refactor: Rewrite imports with .ts extensions (#40700 )

2026-01-26 22:48:17 +00:00

dep-types.ts

docs: explicitly document depTypes each manager supports (#42142 )

2026-03-31 12:08:39 +00:00

extract.spec.ts

refactor: Rewrite imports with .ts extensions (#40700 )

2026-01-26 22:48:17 +00:00

extract.ts

refactor: Rewrite imports with .ts extensions (#40700 )

2026-01-26 22:48:17 +00:00

index.ts

docs: explicitly document depTypes each manager supports (#42142 )

2026-03-31 12:08:39 +00:00

readme.md

fix(kustomize): Fix artifact inflate option (#35071 )

2025-03-30 07:04:51 +00:00

types.ts

feat(manager/kustomize): Support inflating helm charts (#34277 )

2025-03-26 13:38:46 +00:00

readme.md

Renovate can manage these parts of the kustomization.yaml file:

remote resources
image tags
components
helm charts
remote bases (deprecated since Kustomize v2.1.0)

How It Works

Renovate searches in each repository for any kustomization.yaml files
Dependencies are extracted from remote bases, image tags and Helm charts
Renovate resolves the dependency's source repository and checks if there are SemVer tags
If Renovate finds an update, then it updates the kustomization.yaml file

This manager uses three depTypes to allow fine-grained control of which dependencies are upgraded:

Component
Kustomization
HelmChart
OCIChart

Helm charts inflation

Renovate will inflate helm charts referenced in a kustomization if any of the following is true:

The version Renovate is upgrading from was inflated, OR
The kustomizeInflateHelmCharts option in postUpdateOptions is enabled

Note: To prevent Renovate from updating dependencies in the expanded charts, you'll need to manually exclude the folders from Helm managers. For example:

{
  "packageRules": [
    {
      "matchFileNames": ["**/charts/**"],
      "matchManagers": ["helmv3", "helm-values"],
      "enabled": false
    }
  ]
}

Limitations

Using HTTPS to fetch the repositories is not tested
The keys for the image tags can be in any order

- name: image/name
  newTag: v0.0.1
# or
- newTag: v0.0.1
  name: image/name

Digests can be pinned in newTag or digest:

- name: image/name
  newTag: v0.0.1@sha256:3eeba3e2caa30d2aba0fd78a34c1bbeebaa1b96c7aa3c95ec9bac44163c5ca4f
# without a version, digests are tracked as :latest
- name: image/name
  digest: sha256:3eeba3e2caa30d2aba0fd78a34c1bbeebaa1b96c7aa3c95ec9bac44163c5ca4f

The image's repository can be changed with newName:

- name: image/name
  newName: custom-image/name:v0.0.1
- name: image/name
  newName: custom-image/name:v0.0.1@sha256:3eeba3e2caa30d2aba0fd78a34c1bbeebaa1b96c7aa3c95ec9bac44163c5ca4f
- name: image/name
  newName: custom-image/name@sha256:3eeba3e2caa30d2aba0fd78a34c1bbeebaa1b96c7aa3c95ec9bac44163c5ca4f
- name: image/name
  newName: custom-image/name
  newTag: v0.0.1@sha256:3eeba3e2caa30d2aba0fd78a34c1bbeebaa1b96c7aa3c95ec9bac44163c5ca4f
- name: image/name
  newName: custom-image/name
  digest: sha256:3eeba3e2caa30d2aba0fd78a34c1bbeebaa1b96c7aa3c95ec9bac44163c5ca4f

Images with values ignored by Kustomize will be skipped to avoid ambiguity:

# bad: skipped because newTag: is ignored when digest: is set
- name: image/name
  newTag: v0.0.1
  digest: sha256:3eeba3e2caa30d2aba0fd78a34c1bbeebaa1b96c7aa3c95ec9bac44163c5ca4f
# good:
- name: image/name
  newTag: v0.0.1@sha256:3eeba3e2caa30d2aba0fd78a34c1bbeebaa1b96c7aa3c95ec9bac44163c5ca4f