Do not add renovate/stability-days check in case of internalChecksFilter=strict

[Inok]

We use self-hosted GitLab with external pipelines, so, when we use stabilityDays option, Renovate does not detect external pipelines and merges changes immediately (#7800).

#7800 potentially solves our problem (and it would be great if it will be implemented), but here is another (hopefully, simpler) approach.

What if Renovate doesn't add renovate/stability-days at all if internalChecksFilter=strict is enabled? In that case, renovate/stability-days will always be successful (because if it's not, PR won't be created). So there is no need to add that check to the PR.

Maybe that behavior should be optional (e.g. addStabilityDaysCheck=always(default)/only-if-pending).

[rarkins]

The ultimate problem is Renovate automerging right away right, not some other process?

If we remove the status check it might be a breaking change for anyone who has this setting and is not automerging.

[Inok]

Yes, Renovate automerges PRs right after rebasing, because it doesn't know about pending external pipelines. And if several PRs are open, Renovate will rebase and merge all of them sequentially in a single run.

It seems that there is no reason for adding that check to PR in case it's known to be successful initially.
It's a breaking change if enable it by default. But a new option like addStabilityDaysCheck=always(default)/only-if-pending will solve that problem. The behavior won't change unless that new option will be applied.

The only concern I have is: what to do if settings changed and the stability period increases. In that case, a previously successful check becomes pending. Adding it to the PR gets us back to the initial issue.
But maybe it's ok to not add that check if PR already exists. If PR was created before changing settings - it seems ok to apply older restrictions to it.

[rarkins]

Renovate should not/does not automerge more than one PR per run. Please include logs if that's what's your seeing, or delete it if it's mistaken.