Update Docker image on kubernetes deployment files

[AndreaGiardini]

It would be nice to have the possibility to have the docker image update logic also for Kubernetes deployment files.

Dependabot will have to scan all yml/yaml files, get the image field and check for updates of the docker image.

[greysteil]

Agreed! @hmarr - any thoughts on what this would look like as a "package manager"?

[RohanNagar]

Along these lines, support for docker-compose would be awesome as well! This is also described in dependabot/feedback#82

The images are defined in the same way as in the Kubernetes files: docker-compose is a yaml file and the images are defined in image fields.

[AndreaGiardini]

@greysteil @hmarr Is it something we can contribute to? Any suggestion is appreciated

[greysteil]

Totally is - I can think of two ways:

1. all of the work on this one will be in dependabot-core. Happy to talk you through what needs doing there - maybe take a look at the readmes (particularly this section) first? Actually adding the code yourself would be quite a big undertaking - it's quite a big codebase these days!
2. a smaller, more accessible way to help would be to put together a bunch of fixtures, commented up with the kind of updates you'd want from Dependabot on them. A PR into Dependabot Core that just added those (under the spec/fixtures directory) which a bunch of comments on GitHub would make it way easier for me to pick this up.

Thanks for your enthusiasm on this one, and sorry for letting it stall. Lots on at the mo!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within seven days. Thank you for your contributions.

[genebean]

+1 to this functionality

[ajcann]

Would be great to see this - checking yaml in specified folders for the key containers: [ image: ] for kubernetes and probably explicit specification of a docker-compose file looking for: services: { : image: }

[steinbrueckri]

+1 to this functionality

[gavinelder]

+1 to this functionality

[devstein]

+1

[RappC]

+1
Also our Gitops Repositories with multiple deployment kubernetes manifests would benefit from this feature. Any plans until when we can expect this feature?

[ChipWolf]

+1
I also think it would be a good addition to allow some arbitrary regex to select the location of the dependancy in code and the ability to specify a source of the current version.

Take this HelmRelease definition as an example:
workloads/rabbitmq/helm-release.yaml

apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
...
spec:
  chart:
    repository: https://kubernetes-charts.storage.googleapis.com/
    name: rabbitmq
    version: 3.3.6

The following regex will match any valid major.minor.patch version in this file:

^    version: (0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)?$

My dependabot config would then become something along the lines of:

version: 1
update_configs:
  - package_manager: "generic"
    directory: "/"
    update_schedule: "weekly"
    configs:
      - source: "https://raw.githubusercontent.com/bitnami/charts/master/bitnami/rabbitmq/Chart.yaml"
        source_match: "^version: (0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)?$"
        destination: "workloads/rabbitmq/helm-release.yaml"
        destination_match: "^    version: (0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)?$"

I note the Renovate project appears to meet these particular requirements.
Any thoughts?

[jglick]

See also #2237.

[JesperTerkelsen]

+1

[jeffwidman]

Support for this was merged in #5348 🎉

[Raboo]

@jeffwidman is it the package-ecosystem: "docker" that is used for Kubernetes YAML files?

[dimisjim]

@Raboo seems to be so yeah, based on: #5348 (comment)

It is added onto the Docker package.

as it's also the only one in the doc right now: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#package-ecosystem

[jeffwidman]

Currently this is buried behind a feature flag for folks on GitHub.com...

We'd like to start slowly rolling it out for everyone, but before I do that, I'd like to test on a few repos to ensure no unexpected issues. I can / will setup a fake test repo, but there's nothing like live data to confirm things.

Anyone watching this issue care to volunteer to have their repo(s) be part of the beta test?

Repos must match the following criteria:

• on GitHub.com
• public, because for security reasons we can't access private repos w/o jumping through some hoops
• have k8s deployment yaml files... ideally with a combination of up-to-date and outdated docker image tags

If interested, please comment on this thread with the URLs of any repos you own/maintain. Once I get a couple of volunteers, no need to keep volunteering... I expect/hope the rollout should be pretty quick, so you won't be waiting too long.

[chadlwilson]

Hi @jeffwidman Is this intended to support Helm templates? Or only raw K8s YAML?

https://github.com/gocd/helm-chart/tree/master/gocd is a Helm chart, so the deployment YAMLs are templates (first, second, third but is a Job). They are reading values from values file defaults, so are non-trivial unless the implementation renders a template somehow or "understands" Helm norms.

Please ignore if only intended to support raw YAML. 🙏

[jeffwidman]

@chadlwilson this change will support both raw K8s YAML and Helm files, but only docker image tags within those files:

• Add support for bumping docker container versions referenced from within Helm files #5738

As you noted, we'd need a bunch of additional tooling to support actual Helm template inheritance beyond just regex'ing out the docker image tags.

I took a quick look at your repo, and I don't see any image tags in those templates. I also don't see a dependabot.yml stanza for docker, which makes sense because there's no Dockerfile in that repo... so unfortunately not really a fit for a positive test case that we correctly open a PR, nor a negative test case that we don't break existing behavior. Thanks for checking though.

[jeffwidman]

I've enabled the feature flag on 100% of GitHub.com cloud repos, so anyone is now welcome to try this on their repos. If you run into any bugs, please file an issue.

[kpocius]

public, because for security reasons we can't access private repos w/o jumping through some hoops

Is this requirement still true even after full rollout?

We've added the following:

- package-ecosystem: docker
  directory: namespace/traefik/install
  schedule:
    interval: weekly
  rebase-strategy: disabled

But end up with an error:

[kpocius]

Pardon the spam. Turns out there was a typo in the config.