Force on lockFileMaintenance breaks PR creation in Gitlab

[Daniel-I-Am]

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.214.2

Please tell us more about your question or problem

Most of our repositories have a schedule defined for creating their merge requests by Renovatebot. Sometimes, MRs should be created outside that schedule for whatever reason. For that, I have a manually triggered run of Renovatebot with the RENOVATE_FORCE environment variable set.

In the current version this breaks the creation of lockFileMaintenance MRs.

---

The documentation reads:

This object is used as a "force override" when you need to make sure certain configuration overrides whatever is configured in the repository. For example, forcing a null (no) schedule to make sure Renovate raises PRs on a run even if the repository itself or its preset defines a schedule that's currently inactive.

This sounded great and is what I applied:
RENOVATE_FORCE={"schedule":null, "lockFileMaintenance": {"enabled": true, "schedule": null}, "prHourlyLimit": 50} in the Gitlab scheduled pipeline running Renovatebot.
This is also everything needed to reproduce alongside a repository with a pending lockFileMaintenance upgrade.

lockFileMaintenance is marked as 'mergeable' in the documentation. So this should pick up the default configuration, overriding the scheduling.
I am pretty sure it was able to do so in the past, but I was unable to validate this, since we don't use this very often. But it did send me on a wild goose chase leading to this discussion.

However, setting any part of the lockFileMaintenance key using force also seems to remove the default lockFileMaintenance.branchTopic setting, causing Renovate to default to a branch named renovate/.x which is not a valid branchname for Git.
It can be worked around by copying over the entire default value for the 'lockFileMaintenance' configuration block, i.e.:
RENOVATE_FORCE={"schedule":null, "lockFileMaintenance": {"enabled": true, "recreateWhen": "always", "branchTopic": "lock-file-maintenance", "commitMessageAction": "Lock file maintenance", "commitMessageTopic": null, "commitMessageExtra": null, "schedule": null, "groupName": null, "prBodyDefinitions": {"Change": "All locks refreshed"}}, "prHourlyLimit": 50}

---

I think it's a bug that setting lockFileMaintenance overrides the full object rather than only the nested keys that are configured.
I am assuming this is a really niche feature/use-case so maybe just accepting the bug and documenting it is sufficient. If there was a warning in the docs for force saying 'when overriding lockFileMaintenance, the entire object is overridden including the branch name leading to unpredictable behavior', it would have saved me many hours of debugging 😅

However, looking at the sledgehammer I am using to solve a scheduling problem, this might also be a feature request. Which is to allow the behavior mentioned in the documentation, bypassing configured schedules, without having to reach out to force. I would not mind a ignoreSchedule setting in the self-hosted options for accomplishing this behavior.

Logs (if relevant)

Logs

(latest logs I have that are somewhat small enough to dig through were of a failed branch, so it ends with no-work, but still shows the branch naming issue after branchifyUpgrades.

DEBUG: branchifyUpgrades (repository=<username>/<project>)
DEBUG: detectSemanticCommits() (repository=<username>/<project>)
DEBUG: getCommitMessages (repository=<username>/<project>)
DEBUG: semanticCommits: score=-20 (repository=<username>/<project>)
DEBUG: semanticCommits: disabled (repository=<username>/<project>)
DEBUG: Filtered out 78 disabled update(s). 2 update(s) remaining. (repository=<username>/<project>)
DEBUG: 2 flattened updates found:  (repository=<username>/<project>)
DEBUG: Returning 1 branch(es) (repository=<username>/<project>)
DEBUG: Branch is not pending, removing pending upgrades (repository=<username>/<project>, branch=renovate/.x)
DEBUG: config.repoIsOnboarded=true (repository=<username>/<project>)
DEBUG: packageFiles with updates (repository=<username>/<project>, baseBranch=master)
       "config": {
         "npm": [
           {
             "deps": [
               // irrelevant
             ],
             "extractedConstraints": {"node": "^24.0.0", "pnpm": "10.33.0"},
             "managerData": {
               "packageJsonName": "redacted",
               "hasPackageManager": true,
               "pnpmShrinkwrap": "src/frontend/pnpm-lock.yaml",
               "yarnZeroInstall": false,
               "npmrcFileName": null
             },
             "skipInstalls": true,
             "packageFile": "src/frontend/package.json",
             "lockFiles": ["src/frontend/pnpm-lock.yaml"]
           },
           {
             "deps": [],
             "managerData": {"pnpmShrinkwrap": "src/frontend/pnpm-lock.yaml"},
             "packageFile": "src/frontend/pnpm-workspace.yaml",
             "lockFiles": ["src/frontend/pnpm-lock.yaml"]
           }
         ]
       }
DEBUG: detectSemanticCommits() (repository=<username>/<project>)
DEBUG: semanticCommits: returning "disabled" from cache (repository=<username>/<project>)
DEBUG: processRepo() (repository=<username>/<project>)
DEBUG: Processing 1 branch: renovate/.x (repository=<username>/<project>)
// irrelevant: Processing of the branch in Renovate goes without any errors
 INFO: DRY-RUN: Would ensure Dependency Dashboard (repository=<username>/<project>)
       "title": "Dependency Dashboard"
DEBUG: checkReconfigureBranch() (repository=<username>/<project>)
DEBUG: No reconfigure branch found (repository=<username>/<project>)
       "reconfigureBranch": "renovate/reconfigure"
DEBUG: Removing any stale branches (repository=<username>/<project>)
DEBUG: config.repoIsOnboarded=true (repository=<username>/<project>)
DEBUG: Branch lists (repository=<username>/<project>)
       "branchList": ["renovate/.x"],
       "renovateBranches": ["renovate/lock-file-maintenance"]
DEBUG: remainingBranches= (repository=<username>/<project>)
DEBUG: No branches to clean up (repository=<username>/<project>)
 INFO: DRY-RUN: Would save repository cache. (repository=<username>/<project>)
DEBUG: ensureIssueClosing() (repository=<username>/<project>)
DEBUG: ensureIssueClosing() (repository=<username>/<project>)
DEBUG: PackageFiles.clear() - Package files deleted (repository=<username>/<project>)
DEBUG: Branch summary (repository=<username>/<project>)
       "cacheModified": undefined,
       "baseBranches": [{"branchName": "master", "sha": "0088d7394d3da63c530f26f4bc72fdf11d5cc136"}],
       "branches": [],
       "defaultBranch": "master",
       "inactiveBranches": ["renovate/.x"]
DEBUG: branches info extended (repository=<username>/<project>)
       "branchesInformation": [
         {
           "branchName": "renovate/.x",
           "prNo": null,
           "prTitle": "Renovate: Update dependency to",
           "result": "no-work",
           "upgrades": [
             {
               "displayPending": "",
               "packageFile": "src/frontend/pnpm-workspace.yaml",
               "updateType": "lockFileMaintenance"
             },
             {
               "displayPending": "",
               "packageFile": "src/frontend/package.json",
               "updateType": "lockFileMaintenance"
             }
           ]
         }
       ]