adding --include-forked fails if it's the last argument before floating arguments

[jessehouwing]

How are you running Renovate?

Self-hosted

If you're self-hosting Renovate, tell us what version of Renovate you run.

latest

If you're self-hosting Renovate, select which platform you are using.

github.com

If you're self-hosting Renovate, tell us what version of the platform you run.

github

Was this something which used to work for you, and then stopped?

I never saw this working

Describe the bug

I tried to figure out what's going on and there is a special case that causes an issue, which is what I was trying to work around.

When I call

npx renovate --include-forked jessehouwing/renovate

I get an error:

renovate --include-forks jessehouwing/renovatebot
FATAL: Fatal error: Invalid boolean value: expected 'true' or 'false', but got 'jessehouwing/renovatebot'
       "err": {
         "message": "Invalid boolean value: expected 'true' or 'false', but got 'jessehouwing/renovatebot'",
         "stack": "Error: Invalid boolean value: expected 'true' or 'false', but got 'jessehouwing/renovatebot'\n    at Option.boolean [as parseArg] (C:\\Users\\JesseHouwing\\AppData\\Roaming\\fnm\\node-versions\\v18.12.1\\installation\\node_modules\\renovate\\lib\\workers\\global\\config\\parse\\coersions.ts:12:11)\n    at handleOptionValue (C:\\Users\\JesseHouwing\\AppData\\Roaming\\fnm\\node-versions\\v18.12.1\\installation\\node_modules\\renovate\\node_modules\\commander\\lib\\command.js:539:24)\n    at Command.<anonymous> (C:\\Users\\JesseHouwing\\AppData\\Roaming\\fnm\\node-versions\\v18.12.1\\installation\\node_modules\\renovate\\node_modules\\commander\\lib\\command.js:566:7)\n    at Command.emit (node:events:513:28)\n    at Command.emit (node:domain:489:12)\n    at Command.parseOptions (C:\\Users\\JesseHouwing\\AppData\\Roaming\\fnm\\node-versions\\v18.12.1\\installation\\node_modules\\renovate\\node_modules\\commander\\lib\\command.js:1461:18)\n    at Command._parseCommand (C:\\Users\\JesseHouwing\\AppData\\Roaming\\fnm\\node-versions\\v18.12.1\\installation\\node_modules\\renovate\\node_modules\\commander\\lib\\command.js:1240:25)\n    at Command.parse (C:\\Users\\JesseHouwing\\AppData\\Roaming\\fnm\\node-versions\\v18.12.1\\installation\\node_modules\\renovate\\node_modules\\commander\\lib\\command.js:909:10)\n    at Object.getConfig (C:\\Users\\JesseHouwing\\AppData\\Roaming\\fnm\\node-versions\\v18.12.1\\installation\\node_modules\\renovate\\lib\\workers\\global\\config\\parse\\cli.ts:115:6)\n    at parseConfigs (C:\\Users\\JesseHouwing\\AppData\\Roaming\\fnm\\node-versions\\v18.12.1\\installation\\node_modules\\renovate\\lib\\workers\\global\\config\\parse\\index.ts:22:31)\n    at C:\\Users\\JesseHouwing\\AppData\\Roaming\\fnm\\node-versions\\v18.12.1\\installation\\node_modules\\renovate\\lib\\workers\\global\\index.ts:122:16\n    at start (C:\\Users\\JesseHouwing\\AppData\\Roaming\\fnm\\node-versions\\v18.12.1\\installation\\node_modules\\renovate\\lib\\workers\\global\\index.ts:120:5)\n    at C:\\Users\\JesseHouwing\\AppData\\Roaming\\fnm\\node-versions\\v18.12.1\\installation\\node_modules\\renovate\\lib\\renovate.ts:18:22"
       }

It looks like other booleans don't suffer this fate:

renovate --include-forks --dry-run jessehouwing/renovate

Works just fine, possibly because --dry-run is auto migrated to --dry-run=true.

I'm not at all sure how to fix this.

Adding a migration from --include-forks to --include-forks=true fixes the issue, but I'm not sure it's the best way to proceed:

• fix: When --include-forks is passed, assume =true #20206

Relevant debug logs

Logs

Copy/paste the relevant log(s) here, between the starting and ending backticks

Have you created a minimal reproduction repository?

I have linked to a minimal reproduction repository in the bug description

[rarkins]

The underlying CLI library we use seems a little bit quirky at times, although I'm not sure if they're doing anything wrong. I'm pretty sure that everything works properly if you always put =true for boolean params.

As I mentioned in the PR, we're not wanting those CLI fix-ups to be "permanent" - they're more like hacks. We should probably log a warn whenever commands are migrated so that users are hopefully aware and we can eventually remove them all.