feat(gitlab): add branch status check attemps

[philippe-granet]

Changes

• Add branch status check attemps before trying to add status check
• Allow overriding the branch status check attempts via experimental env RENOVATE_X_GITLAB_BRANCH_STATUS_CHECK_ATTEMPS.

Context

• GitLab external job "renovate/stability-days" treated as passing status check even when tests fail #27111
• feat(platform/gitlab): Allow custom delay for pipeline status via experimental variable #23239
• GitLab: Two pipelines per MR #5743

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[rarkins]

Could this instead be default functionality, with a large number of attempts, e.g. 10?

[philippe-granet]

Could this instead be default functionality, with a large number of attempts, e.g. 10?

This will penalize projects that do not have defined pipelines, this will systematically wait 10s and slow down the renovate analyzes

[rarkins]

Could this instead be default functionality, with a large number of attempts, e.g. 10?

This will penalize projects that do not have defined pipelines, this will systematically wait 10s and slow down the renovate analyzes

Thanks for the info. I think I missed this from the various conversations before. Could make sure this info of when this is setting is applicable and when it's not is captured in the markdown doc in this PR? I will then decide if it needs to be a first-class option or brainstorm if we have a clever way to detect this. If this is a common problem we prefer that users don't need to set obscure experimental options.

[philippe-granet]

Could this instead be default functionality, with a large number of attempts, e.g. 10?

This will penalize projects that do not have defined pipelines, this will systematically wait 10s and slow down the renovate analyzes

Thanks for the info. I think I missed this from the various conversations before. Could make sure this info of when this is setting is applicable and when it's not is captured in the markdown doc in this PR? I will then decide if it needs to be a first-class option or brainstorm if we have a clever way to detect this. If this is a common problem we prefer that users don't need to set obscure experimental options.

Done in this commit :5a3f6d3 (#32692)