search

davidalger / capistrano-magento2

Magento 2 specific tasks for Capistrano 3
https://rubygems.org/gems/capistrano-magento2
Open Software License 3.0
228 stars 75 forks source link

Running capistrano with the optional argument --dry-run fails on version check #128

Closed jamescowie closed 4 years ago

jamescowie commented 5 years ago

When running capistrano one of the default options is to -dry-run which is especially handy when creating more complex deployments. However when running dry-run with the capistrano-magento2 gem it fails with: 

00:03 composer:run
      01 composer install --ignore-platform-reqs --no-interaction --quiet --optimize-autoloader
00:03 magento:deploy:version_check
      ERROR Version 0.7.0 and later of this gem only support deployment of Magento 2.1.1 or newer; attempted to deploy v. Please try again using an earlier version of this gem!

Initial investigation is that because the dry-run only looks at the commands being ran and never actually executes them then we are not able to obtain the accurate version of Magento and as such the version_check function fails.

Im not sure on what the "best practice" policy is on validating conditions in functions. I will research more on what is normal for other gems and report back :)

davidalger commented 5 years ago

@jamescowie Interesting. I've never tried to use that flag before. It does appear with minimal research that there is means in SSHKit to detect when dry-run is set. The most interesting thing though is, with the purpose of --dry-run being to print out all the commands run during execution, I'm coming up empty on how to make this work correctly without simply dropping support for older versions of M2. I'm open to suggestions. The magento_version method exists because it's used to determine which code path is different, as determined by the Magento version. An example would be SCD where it's output has to be parsed vs just running the command, or where SCD supports deploy strategies on 2.2.x but not 2.1.x.

I'll have to have a look at this, but I suspect it might work to just drop 2.1 support given it is pending EOL and issue a new minor version bump as most of (if not all) the version differences are between 2.1 and 2.2 IIRC. Nothing in this gem should be changing for 2.1 at this point, so essentially it would mean those still deploying 2.1.x sites should remain on version 0.8.x of this gem. If I could drop 2.1 support and the check only exists for determining minimal supported version, then it would work to simply ignore the version check on a dry run.

davidalger commented 4 years ago

The --dry-run flag should now work as of version 0.9.0 of this gem.