GitLab: setBranchStatus crashes ("err.body?.message?.startsWith is not a function") when GitLab rejects the stability-status target_url

[BigMichi1]

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

GitLab (.com or self-hosted)

Which version of Renovate are you using?

43.233.3

Please tell us more about your question or problem

There are two bugs here. A GitLab platform change exposed bug (1), and bug (2) turns a recoverable API error into an aborted branch.

Summary

On a self-hosted GitLab (19.0.2-ee, also 19.1.0-ee), every branch that has a renovate/stability-days status fails with WARN: Error updating branch and the MR is never finalized. The runner
still exits 0, so it's silent unless you read per-branch logs.

The root cause is the target_url Renovate sends for the stability status.

Bug 1 — setStability emits a scheme-less (relative) target_url

In lib/workers/repository/update/branch/status-checks.ts, setStability builds the URL as:

const docsLink = joinUrlParts(
  coerceString(config.productLinks?.documentation),
  'key-concepts/minimum-release-age/',
);

When productLinks.documentation is empty/unset, coerceString(...) returns '' and joinUrlParts('', 'key-concepts/minimum-release-age/') yields the relative string
key-concepts/minimum-release-age/ (no http(s):// scheme). This is then passed as the status target_url.

GitLab 19.0.2+ validates target_url and rejects the missing scheme:

POST /api/v4/projects/<project>/statuses/<sha>
→ 400 Bad Request
   { "message": { "target_url": ["is blocked: Only allowed schemes are http, https"] } }

(Older GitLab accepted the relative value, which is why this only started failing after a GitLab upgrade.)

Bug 2 — setBranchStatus assumes err.body.message is a string

In lib/modules/platform/gitlab/index.ts (~L1047), the catch block does:

if (
  err.body?.message?.startsWith(
    'Cannot transition status via :enqueue from :pending',
  )
) { ... }

GitLab returns the validation error with message as an object ({ "target_url": [ ... ] }), so .startsWith is not a function:

TypeError: err.body?.message?.startsWith is not a function
    at Proxy.setBranchStatus (lib/modules/platform/gitlab/index.ts:1047:26)
    at setStatusCheck (lib/workers/repository/update/branch/status-checks.ts:56:5)
    at setStability (lib/workers/repository/update/branch/status-checks.ts:109:3)
    at setBranchStatusChecks (lib/workers/repository/update/branch/index.ts:64:3)
    at processBranch (lib/workers/repository/update/branch/index.ts:779:5)

The ?. chain guards null/undefined but not a non-string. The thrown TypeError escapes the intended "ignore this transition error" path and propagates up as Error updating branch,
aborting the branch so the PR/MR is never created or finalized.

Suggested fixes

• Bug 2: guard the type, e.g. is.string(err.body?.message) && err.body.message.startsWith(...). This alone stops the crash and makes the error ignorable/recoverable regardless of GitLab's
  response shape.
• Bug 1: don't pass a relative target_url. Omit target_url (or only set it when it's an absolute URL) when productLinks.documentation is empty, instead of sending a scheme-less path.

Logs

DEBUG: Updating renovate/stability-days status check state to green (branch=renovate/claude-2.1.x)
DEBUG: POST https://<gitlab>/api/v4/projects/<project>/statuses/<sha> = (code=ERR_NON_2XX_3XX_RESPONSE, statusCode=400 retryCount=0)
DEBUG: Gitlab API error
       "response": {
         "statusCode": 400,
         "statusMessage": "Bad Request",
         "body": {
           "message": { "target_url": ["is blocked: Only allowed schemes are http, https"] }
         }
       }
WARN: Error updating branch (branch=renovate/claude-2.1.x)
      "err": { "message": "err.body?.message?.startsWith is not a function" }
      TypeError: err.body?.message?.startsWith is not a function
          at Proxy.setBranchStatus (lib/modules/platform/gitlab/index.ts:1047:26)
          at setStatusCheck (lib/workers/repository/update/branch/status-checks.ts:56:5)
          at setStability (lib/workers/repository/update/branch/status-checks.ts:109:3)
          at setBranchStatusChecks (lib/workers/repository/update/branch/index.ts:64:3)
          at processBranch (lib/workers/repository/update/branch/index.ts:779:5)

Have you created a minimal reproduction repository?

No reproduction, but I have detailed evidence (see logs)

Additional context

• Platform: self-hosted GitLab 19.0.2-ee and 19.1.0-ee (both reproduce). Renovate 43.233.3.
• Trigger: a GitLab patch upgrade that began validating commit-status target_url. Bisecting hourly runner logs, the first failure appears the moment GitLab was upgraded, with no change in
  Renovate version or config across the boundary.
• Workaround (confirmed): set an absolute productLinks.documentation (e.g. https://docs.renovatebot.com/) so the emitted target_url becomes
  https://docs.renovatebot.com/key-concepts/minimum-release-age/, which GitLab accepts.

Logs (if relevant)

Logs

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

[tlex]

Affected by the same thing. I have the feeling the changes introduced by #44098 have this unintended side-effect on GitLab. I have exactly the same problem on gitlab.com (and with v43.231.4 this didn't happen).

I've created now #44126, let's hope the maintainers have time to look at it.

Until then, my only workaround was to put this in my default.json, to disable the extra status check gitlab job:

    "statusCheckNames": {
        "minimumReleaseAge": null
    }

[elpro-mabran]

ACK, for now pinning the image on 43.231 solves the issue as well:

variables:
  CI_RENOVATE_IMAGE: ghcr.io/renovatebot/renovate:43.231

[levrik]

Fix has been released 28 minutes ago.

[lethargosapatheia]

For in case this helps, I can confirm that the issue also affects Renovate version 43.233.2 Gitlab CE 18.10.3.