Determine updates after another

[astellingwerf]

How are you running Renovate?

Self-hosted Renovate

If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.

39.134.0 on GitLab

Please tell us more about your question or problem

Imagine I have a repology dependency alpine_3_20/ca-certificates-bundle=20240705-r0 and two custom managers:

1. One to update the the Alpine version in the depName
2. One to update the CA cert bundle version

When a new version of Alpine is released, how can I make Renovate (re)check the CA cert bundle version after the first manager has updated the name of the repology dependency, so that there is one MR bringing us fully up to date on Alpine and its package?

Logs (if relevant)

Logs

Replace this text with your logs, between the starting and ending triple backticks

[rarkins]

Are there any reasons you need to use separate managers in the first place? i.e. is that ideal, or itself due to limitations in Renovate's ability to update strings with "dual" versions in them? I would otherwise suggest using regex versioning and breaking the 3, 20, 20240705 and 0 parts up using that

[astellingwerf]

I need two managers because I need to datasources: The Alpine docker image is in a docker repo, and the Alpine packages are to be monitored through repology.
I can't use your suggestion (and I don't think it would even help us here), as this is just one of the example out of a list of 15 Alpine packages. If we update the Alpine version, we want to also update all the package versions in the same MR.

[adam-moss]

We are also looking for a solution to this issue when using the recommended annotations for repology in conjunction with the dockerVersions preset.

At the moment we quite often end up with broken pipelines on the MR raised due to the mismatch between the actual image and the dependency annotated in the _VERSION strings.

In the below example when Renovate has updated the docker:27.3.1 tag to docker:28.0.0 tag I have had to manually update the annotations and the cosign version to allow the pipeline to succeed.

- FROM docker:27.3.1@sha256:6ca9a6811085e2cf769cbac04bc47daf66629102990391caab7cf37426e939da
+ FROM docker:28.0.0@sha256:e0b121dfc337c0f5a9703ef0914a392864bde6db811f2ba5bdd617a6e932073e

ARG PROXY_CA_CERT

- # renovate: datasource=repology depName=alpine_3_20/jq versioning=loose
+ # renovate: datasource=repology depName=alpine_3_21/jq versioning=loose
ARG JQ_VERSION=1.7.1-r0
- # renovate: datasource=repology depName=alpine_3_20/cosign versioning=loose
- ARG COSIGN_VERSION=2.2.1-r5
+ # renovate: datasource=repology depName=alpine_3_21/cosign versioning=loose
+ ARG COSIGN_VERSION=2.4.1-r2

RUN apk --no-cache update \
  && apk --no-cache add \
    jq=${JQ_VERSION} \
    cosign=${COSIGN_VERSION} \
  && addgroup -g 65532 nonroot \
  && adduser -u 65532 -G nonroot -s /bin/sh -D nonroot

USER nonroot

I guess this case is more complicated since you have to somehow know docker:28.0.0 is based on alpine 3.21... is there a way to provide this via annotation too for renovate to consume?

[astellingwerf]

I tried and realized that Renovate can run on its own branches too: https://github.com/astellingwerf/recursive-renovation/blob/main/renovate.json5
I configured it to recognize and update the comments for the repology dependencies. For the case that @adam-moss describes, one could maybe use postUpgradeTasks to analyse the updated image reference and adjust the comment accordingly in the initial update, so that the second update is based on that adjusted version.