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

[4ctobias]

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

[m2-assistant]

Hi @4ctobias. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

• Summary of the issue
• Information on your environment
• Steps to reproduce
• Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, please, review the Magento Contributor Assistant documentation.

Please, add a comment to assign the issue: @magento I am working on this

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

⚠️ According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.

🕙 You can find the schedule on the Magento Community Calendar page.

📞 The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket.

🎥 You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel

✏️ Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

[yogesh-valiya]

@magento I am working on this

[yogesh-valiya]

If said in short, you are supposed to pass the value of the flag like --dry-run=1 or --dry-run 1.

Magento uses the Symfony framework for command-line utility. And as per the Symfony documentation, you can use an option without value if the type of the option is set to \Symfony\Component\Console\Input\InputOption::VALUE_NONE. But the type of the option dry-run is set to \Symfony\Component\Console\Input\InputOption::VALUE_OPTIONAL.

magento2/setup/src/Magento/Setup/Console/Command/UpgradeCommand.php

Lines 118 to 125 in a4071d4

	new InputOption(
	DryRunLogger::INPUT_KEY_DRY_RUN_MODE,
	null,
	InputOption::VALUE_OPTIONAL,
	'Magento Installation will be run in dry-run mode',
	false
	)
	];

So if you don't pass any value to option dry-run Magento will consider the equivalent of null (false).

I think that kind of behavior is appropriate though and the boolean type of option should be the type of InputOption::VALUE_NONE.

[4ctobias]

@yvaliya Confirm.

In short: It should be same as for the --keep-generated-parameter: If specified the mode should be applied, a definition of a further value is not required to enable this mode.

The question here is: Does it make sense to apply this change also for the --safe-mode, --data-restore and --convert-old-scripts parameters as here the issue is the same?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 14 days if no further activity occurs. Is this issue still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? Thank you for your contributions!

[4ctobias]

@magento I am working on this

[m2-assistant]

Hi @4ctobias! 👋
Thank you for collaboration. Only members of Community Contributors Team are allowed to be assigned to the issue. Please use @magento add to contributors team command to join Contributors team.

[4ctobias]

@magento add to contributors team

[m2-assistant]

Hi @4ctobias! 👋
Thank you for joining. Please accept team invitation 👉 here 👈 and add your comment one more time.

[4ctobias]

@magento I am working on this