Should (certain) warnings be errors if the platform has no issue management?

[astellingwerf]

Tell us more.

Someone added a stray comma to their renovate.json file in our Bitbucket Server instances. The now malformed JSON content triggered a warning:

 WARN: Repository has invalid config (repository=~USERID/renovate-sandbox)
       "error": {
         "message": "config-validation",
         "stack": "Error: config-validation\n    at Object.renovateRepository (/usr/local/renovate/lib/workers/repository/index.ts:110:13)\n    at attributes (/usr/local/renovate/lib/workers/global/index.ts:198:11)\n    at start (/usr/local/renovate/lib/workers/global/index.ts:183:7)\n    at /usr/local/renovate/lib/renovate.ts:19:22"
       }

Renovate then attempted to create an issue for it, but since Bitbucket Server does not support that, it merely logged a warning for the fact that it could not ensure the issue, and continued its work as normal.

 WARN: Cannot ensure issue (repository=~USERID/renovate-sandbox)
       "title": "Action Required: Fix Renovate Configuration"

As a result, the project is neutered from a Renovate perspective, and only once people start to miss updates and report it, will we look at it.

Does it make sense to escalate certain warnings to an error that causes the Renovate process to fail once done (not necessarily immediately), if the platform has no issue management?

Developer sidenote

This MAY be easier to implement when we can split the issue management functions from the platform API into it's own API. I've already considered this multiple times, and even started working on that. I dream of a situation where we can add issue management support to Renovate runs against platforms that don't normally support it, such as Bitbucket Server and Local. I'd be open to work on that as a contribution, should you feel that it makes sense.