As for the discussion on having a "DIGEST" label:
I added it because it is part of OCI standard annotations. Personally, I am not depending on it, but I can imagine it being useful to have the digest of the base image in downstream images. It may help to make sure that multi-stage builds downsteams (e.g. actinia) can add stuff using the same base image... Just my not very educated idea of a possible use case ...

In order to keep the DIGEST (and BASE_NAME arg) up to date we may add something like the following to renovate configuration (not tested and no idea if that is enough):

{
  "regexManagers": [
    {
      "fileMatch": ["Dockerfile"],
      "matchStrings": [
        "ARG BASE_NAME=(?<depName>.*?):(?<currentVersion>.*?)\\s",
        "ARG DIGEST=(?<currentDigest>.*?)\\s"
      ],
      "datasourceTemplate": "docker",
      "versioningTemplate": "docker"
    }
  ]
}

That said, I can remove those labels if you feel it is not worth the hassle...

As for the discussion on having a "DIGEST" label:

I added it because it is part of OCI standard annotations. Personally, I am not depending on it, but I can imagine it being useful to have the digest of the base image in downstream images. It may help to make sure that multi-stage builds downsteams (e.g. actinia) can add stuff using the same base image... Just my not very educated idea of a possible use case ...

In order to keep the DIGEST (and BASE_NAME arg) up to date we may add something like the following to renovate configuration (not tested and no idea if that is enough):

{

  "regexManagers": [

    {

      "fileMatch": ["Dockerfile"],

      "matchStrings": [

        "ARG BASE_NAME=(?<depName>.*?):(?<currentVersion>.*?)\\s",

        "ARG DIGEST=(?<currentDigest>.*?)\\s"

      ],

      "datasourceTemplate": "docker",

      "versioningTemplate": "docker"

    }

  ]

}

That said, I can remove those labels if you feel it is not worth the hassle...

The regex you show here might be missing something to match back to what to lookup for. I have some complex setup in the Megalinter repo where I extended the default common regex of Dockerfile to our custom yaml format and docs, so most of the updates are done at the right places. They have an example in their docs (unless they removed it since) where they show a common regex to start with, and to try to keep the same conventions as it allows the maximum configurability in most cases.

It usually involves having a comment in the line above to add the extra data.