restore and restore-from isn't working same as #72

[cantonyselim]

This was posted in #72 but since it was closed, I thought I would open a new one just so it was seen.

I am still having this exact issue. When I run staging restore production, I get ! App not found. If I run staging restore-from production, I get

! restore-fromis not a heroku command. ! Seeheroku help` for a list of available commands.
I am the owner of the heroku apps in question they do not belong to an org. Here are my remotes:

production https://git.heroku.com/my-production-app.git (fetch)
production https://git.heroku.com/my-production-app.git (push)
staging https://git.heroku.com/my-staging-app.git (fetch)
staging https://git.heroku.com/my-staging-app.git (push)

[geoffharcourt]

Hi @cantonyselim this feature is not available until v0.9.3 of Parity. I haven't been able to push it out yet because there's an issue with Homebrew packaging due to new gem dependencies.

[cantonyselim]

No worries, is there a work around right now so that I can use parity to restore a database to my staging from production?

[geoffharcourt]

@cantonyselim you should be able to use the existing restore command (restore-from will just be an alias for restore).

[geoffharcourt]

@cantonyselim can you install 0.9.3 and give it a try?

[vfonic]

@geoffharcourt I just tried after installing 0.9.3 and it still gives the same error.

[geoffharcourt]

I'm able to run development restore-from staging on my machine at the moment with 0.9.3. Do you have other versions of parity installed, or is your app using a different Ruby version? What do you get when you type which development?

[vfonic]

The app is using ruby 2.2.1:
$ which development

/Users/viktorfonic/.rvm/gems/ruby-2.2.1/bin/development

$ brew list parity

/usr/local/Cellar/parity/0.9.3/bin/development
/usr/local/Cellar/parity/0.9.3/bin/production
/usr/local/Cellar/parity/0.9.3/bin/staging
/usr/local/Cellar/parity/0.9.3/lib/app/ (9 files)
/usr/local/Cellar/parity/0.9.3/lib/ruby/ (1009 files)
/usr/local/Cellar/parity/0.9.3/lib/vendor/ (200 files)

I always do brew upgrade --all && brew cleanup

$ heroku --version

heroku-toolbelt/3.42.50 (x86_64-darwin10.8.0) ruby/1.9.3
heroku-cli/4.29.4-8a30ba5 (amd64-darwin) go1.6.1
=== Installed Plugins
[email protected]
[email protected]
heroku-config
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

From the other app dir that's using ruby 2.3.0:
$ which development

/usr/local/bin/development

$ staging restore-from production

/Users/viktorfonic/.heroku/client/lib/heroku/jsplugin.rb:109: warning: Insecure world writable dir /usr/local/Cellar/parity in PATH, mode 040777
/Users/viktorfonic/.heroku/client/lib/heroku/jsplugin.rb:109: warning: Insecure world writable dir /usr/local/Cellar/parity in PATH, mode 040777
! Internal server error.
! Run heroku status to check for known platform issues.

[geoffharcourt]

@vfonic for the app at the top, it looks like the Parity gem's executable (in .rvm/gems/) is in front of the Homebrew-installed executable in your path. In that app's folder, run gem uninstall parity and be sure the executable is uninstalled. When you type which development or which staging, you should see the Homebrew location, not the RVM one.

I can't tell if the second app's error has anything to do with interaction with the plugins you have installed.

[geoffharcourt]

We set the parity folder in Cellar to be writable in the Homebrew formula so that if Bundler runs it doesn't trigger a permissions error, but I don't have that same error message about permissions on my machine (using the same versions of heroku-toolbelt and heroku-cli).

[vfonic]

I've uninstalled the old gem together with executables. The error is now the same in every project:

$ which development

/usr/local/bin/development

$ staging restore-from production

! Internal server error.
! Run heroku status to check for known platform issues.

[geoffharcourt]

I'm not sure if this is a parity problem. The report that began this issue was with the restore-from subcommand not being recognized by parity, but what you're getting now looks like the returned response from Heroku when the CLI gets a 500 error from the server.

Can you tail staging with staging tail? Can you take a backup with staging backup?

[vfonic]

Yes, all those commands work.

Speaking of heroku CLI plugins, I don't remember installing any of those. I've just checked now and it seems that those came installed by default together with heroku-toolbelt brew formula. I think it's just the newer versions of heroku CLI display more information than previous ones. Try running heroku --version and see if you get the same output with addons.

Seems like the gem I had (0.9.2) worked for using staging restore production. I've just tried now to re-run staging restore production (on 0.9.3) and it failed with the error above. Indeed it is a different issue. I'll try and see if I can figure out what could be the issue.

[geoffharcourt]

Do you have git remotes defined for the app? We're using git remotes now rather than the app name. What's the output of git remote -v for your app?

[vfonic]

Yes, I have the remotes set. I'm pretty sure v0.9.2 relied on having those set as well.

[geoffharcourt]

@vfonic later this week I'm going to try to push out a development release so we can get some more information about what's not working here.

[vfonic]

@geoffharcourt Thanks Geoff! Let me know when you do and how can I help with providing info you need to look into this.

[cantonyselim]

@geoffharcourt sorry for the late response so I tried restore and had the same error. I did which staging and which production and it also came up as the path in my bin

/usr/local/bin/production
/usr/local/bin/staging

This is with the current install not v0.9.3

[geoffharcourt]

@cantonyselim can you update to v0.9.3? I'm hoping that the changes applied there will resolve your issue.

[geoffharcourt]

@cantonyselim and @vfonic can you install v0.10.0 and test? I've removed external dependencies, so I expect your issues should be resolved. I've been able to execute this successfully from both Rubygems and Homebrew with v0.10.0.