Task wp:core:update trying to run on production instead of on my workstation

[cec]

Hi,

given how capistrano works, to update WP one should update it locally with the built-in task, then add the changed submodule, make a new commit and deploy to production.

If this is correct, one should expect wp:core:update to run locally.
However if I try to run it with cap staging wp:core:update, it attempts to update WP on my staging environment (asks SSH credentials to our staging server).

From the task's definition, I can tell that this is actually running on the server for the specified stage:

  namespace :core do
    desc "Updates the WP core submodule to the latest tag"
    task :update do
      system('
      cd wordpress
      git fetch --tags
      latestTag=$(git tag -l | sort -n -r -t. -k1,1 -k2,2 -k3,3 -k4,4 | sed -n 1p)
      git checkout $latestTag
      ')
      invoke 'cache:repo:purge'
      puts "WordPress submodule is now at the latest version. You should now commit your changes."
    end
  end

The task's body should be wrapped inside a block passed to run_locally like in wp:setup:local.
With the final result looking something like this:

namespace :core do
  desc "Updates the WP core submodule to the latest tag"
  task :update do
    run_locally do
      system('
          cd wordpress
          git fetch --tags
          latestTag=$(git tag -l | sort -n -r -t. -k1,1 -k2,2 -k3,3 -k4,4 | sed -n 1p)
          git checkout $latestTag
      ')
      #invoke 'cache:repo:purge'
      puts "WordPress submodule is now at the latest version. You should now commit your changes."
    end
  end
end

I commented out cache:repo:purge, because I don't understand why the website's repo should be removed. Wouldn't this considerably slow-down deploys?

Did I completely misunderstood the logic of the update process?

If not, can this be fixed? I'd be happy to send a PR with the change if you want me to (in this way I could give something back to the awesome tool you shared with the community).

Thank you very much for this great piece of work.

Cheers,
Cec

[lukewhitehouse]

Hi @cec the wp:core:update does run locally, however, due to the nature of how Capistrano works it still needs to connect to a server beforehand, even if we're not doing anything with that server. In reality, wpdeploy should probably have its own CLI interface for local commands but thats a whole different point.

The cache:repo:purge was put in as sometimes when updating wordpress there can be conflicts between environments (local, staging and even the remote repo itself i.e. github), this causes errors which mean you need to re-clone the repository on the environment (staging/production). I believe this is a bug with the current submodule strategy we are using

[cec]

Hi @lukewhitehouse I now noticed that wp:core:update calls system (local) instead of execute :)

Regarding the cache:repo:purge I actually did come across such conflicts today, complaining that a given hash was not a tree (unable to checkout the repo tag for WP 4.7) on my production server.
Decommenting the purge line and running cap production wp:core:update fixed the issue.
Thank you!

Do you think it might be worth it to mention these conflicts in the section about updating wordpress? Because in the wiki, the example is using the staging environment and this won't fix the conflict in production (if I understand correctly).

[inedev]

Hi @cec and @lukewhitehouse,

I concur with @cec's opinion, that this should be mentioned in the "Updating WordPress Core" section.

$ bundle exec cap staging wp:core:update
Again, an environment always has to be set for a capistrano command, even if not used like above. This command only updates the local WordPress submodule (not any remote environment.)

From the above segment in the docs I was left with the impression, that the stage does not make any difference at all when you update WP and you just have to commit and push to the respective branch and then deploy.

And this went fine the first time I updated WP (running just cap staging wp:core:update and then pushing to both branches and deploying on both stages). However when I tried to do a second WP update using the same process it went fine on staging but gave me the following error on production:

fatal: reference is not a tree: 1ea8e9a4f03f425a6a77c3487528fedd3f33c100
Unable to checkout '1ea8e9a4f03f425a6a77c3487528fedd3f33c100' in submodule path 'wordpress'

Luckily @cec's above answer pointed me in the right direction in the end (after quite some googling) and all I had to do to fix it was run cap production wp:core:update. I guess running cache:repo:purge on production would have fixed it too.

I just think it would be good to mention this in the docs.

Thanks!

[lukewhitehouse]

@cec, @inedev sorry for the massive delay, this has been added to the Usage guide as requested.

[cec]

@lukewhitehouse @inedev thank you both guys