Possible to only create MR's when condition is met?

[syphernl]

We use our own customized Terraform container and have quite a number of Terraform Infra repo's.
Our Terraform container repo is being monitored by Renovate as well and creates a new MR when Hashicorp updates their Docker container.
However, we still need to check that manually (currently) and merge it. After which a new container gets built and pushed to our own registry.

In the mean time for each infra repo an MR is opened updating .terraform-version and versions.tf but the container also needs to be updated.
During this Renovate run this container is not available since it hasn't been merged (and built) yet.

Is there a way to "hold off" on creating an MR for .terraform-version / versions.tf until this particular version is also available in our container registry?
If the container exists during the second run of Renovate (which is a day later) the existing MR's are properly updated with the container change in .gitlab-ci.yml. During it's initial run it results in a failed pipeline, which only gets fixed as when our container is available.

[rarkins]

Which Renovate manager is this -dockerfile, or terraform? I don't fully understand your scenario - it's a little unclear in the above about which parts are updated by Renovate and which bits by your other processes, but let's start with the manager part first. After that, which registry is Renovate currently looking up? i.e. the one that shows new versions which aren't available in your internal registry yet.

[syphernl]

I think my initial question might have not been clear. Hopefully this example helps with resolving that.

Example:

• Terraform releases 0.14.9, we currently use 0.14.8 and have this specified in our local files.
• Renovate would normally update .terraform-version (terraform-version manager) and versions.tf (terraform manager) and replace 0.14.8 with 0.14.9.
• If we have a new Docker container tag (doesn't really matter which version, as long as its higher than the one in our local files) in our registry, it would also update .gitlab-ci.yml (using gitlabci manager)
• This all happens in the same MR because the packageNames group them together.

I would like to have Renovate verify if container:0.14.9 exists in the registry.

• If the container tag exists: Update the .gitlab-ci.yml (alongside the previously changed files).
  In the end it will update: .terraform-version, versions.tf and .gitlab-ci.yml which all contain a reference to 0.14.9.
• If the container tag does not exist: Skip creating the MR. Do not update .terraform-version or versions.tf either.
  During the next Renovate run it will do the check again, if the container tag does exist it would create the MR to update .terraform-version, versions.tf and .gitlab-ci.yml.

[viceice]

you need to configure package rule to use your docker image as datasource. maybe you need to disable default manager handling and use custom regex manager to do this.

By default renovate is not able to do that, it will lookup the version on the configured datasources.

[rarkins]

Thanks, I understand better now. If Renovate looks up the container using your own internal registry, then it would know there's no 0.14.9. But it doesn't have a way to know that it shouldn't update the others if you use the traditional package managers.

If instead you used regex managers for the other files then you could redirect datasource lookupName to point to your internal docker registry so that it doesn't propose an update unless one exists for the Docker image

[syphernl]

Would that be as simple as this?

  {
    packageNames: ['hashicorp/terraform', 'registry.gitlab.com/REDACTED/containers/terraform'],
    lookupName: 'registry.gitlab.com/REDACTED/containers/terraform',
    groupName: 'terraform',
    additionalBranchPrefix: '',
  }

[rarkins]

No, that type of syntax won't work. Please check the documentation and examples for regexManagers. You would need to disable this package in its regular managers and extract it using regex manager instead