Upgrading dependent versions together

[sarahhodne]

We have some dependencies that need to be updated together, and while I know I can group them in a PR, I am wondering if there's some way to "hold" some of the packages until all of them are available?

As an example, we use Terraform, but in CI we are using a custom-build Terraform Docker image with some extra dependencies installed. Currently, when there's a new Terraform version released, we get a Renovate PR that updates the version number in our repository, but because there's no new Docker image built yet, that doesn't get updated. I'm working on enabling Renovate on the repo building the Docker image too, so we can get that built more or less automatically, but I'm wondering if we can configure the repository that uses that image to not open a PR at all until the Docker image is updated?

So, what I want is something like this:

1. New Terraform version is released.
2. Renovate opens PR to our Docker image repo to update the base image version, which will build and push a new Docker image with the new version when merged.
3. Once that is merged and the new image is pushed, Renovate opens a PR in our Terraform repository that updates the Docker image (in the CircleCI config) and the .terraform-version and required_version flags.

Also, a similar but slightly different thing for more examples of what I'm looking for: We use cluster-autoscaler in our cluster, and the version there needs to match our cluster version. Currently we've just configured Renovate to ignore anything except patch versions, and we'll manually bump the minor version to match any time we upgrade the cluster, but it'd be nice if we could somehow have Renovate do that automatically.

[rarkins]

You can perhaps use stabilityDays as a workaround. E.g. if you know that within 1 day the required image is usually available, set stabilityDays=1.

Pretty sure there's a feature request already existing for being able to define something like a "minimum updates in a branch" value for such a case, as in you can decide to suppress the branch until there's 2 updates and not 1.

[HonkingGoose]

We have some issues open that relate to "upgrading dependent versions together.
I copy/pasted a promising quote from the rollup PR issue: ¹

I propose a new concept - rollupName - that would replace the concept of groupName for the majority of users of the second case above. In short, it would "roll up" separate updates into combined PRs only once they passed tests in their own branch. The rolled up PR hopefully then also passes.

rollupName would essentially sit "above" groupName. e.g. you would use groupName for packages that must be updated together, while rollupName can be used to combine multiple groups if desired. For example you'd still keep monorepos using groupName but the "group all" would be better suited for a rollupName.

• roll up updates into single PR #4404
• Force same versions inside package group #12310
• Sync versions within a group #9739

Footnotes

1. https://github.com/renovatebot/renovate/issues/4404 ↩

[nickofthyme]

Another use case for this is say I am using react and react-is. The react-is package is meant to be used with the same major version of react, see facebook/react#31688. So if I'm using [email protected] I would use react-is@^15. Renovate only supports this if you are on the latest major version of react but only because in such case there is an implicit version ceiling such that the two are compatible. This case is not solved using stabilityDays.