magento2: setup:upgrade --dry-run does not work as expected by other dry-run-commands in Linux-environment

Hi,

today a colleague of mine started a setup:upgrade with the parameter --dry-run and expected no database changes either. But in fact we got some database changes that in the specific case turned out our production instance went offline due too some issues with an updated module.

After a investigation we found out the dry-run-parameter expects an optional parameter that will be converted to a true/false value. Only on true the dry-run will be applied - but the default is a false as also the output states:

--dry-run[=DRY-RUN] Magento Installation will be run in dry-run mode [default: false]

This was unexpected as we know no other dry-run-able commands in the linux world that expects as stated above:

• rsync --dry-run => will do an dry run in rsync without transferring any files
• apt-get install --dry-run => will output changes that would be applied by a installation of package without installing anything

Steps to reproduce (*)

1. Change a module so that this module will do some schema changes
2. run setup:upgrade --dry-run

Expected result (*)

1. No database updates should be applied

Actual result (*)

1. Database changes will be applied unless you do something line setup:upgrade --dry-run=1

This is unexpected as it not applies to standards/common dry-run-behavior

As the dry-run-parameter of setup:upgrades can handle an optional value the default should be set to “true” - if a user declares the dry-run-parameter within the command, the user actively wants to start up a dry run. Specifying --dry-run as parameter to “disable” the dry run is not the use case expected by any user.

---

Please provide Severity assessment for the Issue as Reporter. This information will help during Confirmation and Issue triage processes.

• Severity: S0 - Affects critical data or functionality and leaves users without workaround.
• Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.