Issue restoring staging #72
Comments
|
@eignerchris does your application belong to another organization? I've seen this happen on apps that have transferred ownership or that belong to a Heroku org that I am not a part of. |
|
I'm having the same issue with restoring staging. I can execute backup operations and most passthrough commands successfully, but |
|
I have this same issue with a staging remote. But, check it!... It looks like whatever parity code attempts to convert the remote name to a heroku app name is not getting the correct value? In this case, it should be |
|
@geoffharcourt yes the two applications I tested on are not owned by me. I am merely a collaborator. |
|
@mjankowski it turns out the applications I was having a problem with happened to fit the pattern of having been transferred out of the thoughtbot org, so that was a false clue. I think the issue is when the application's folder on the development machine doesn't have the same name as the Heroku app. I just renamed my app that was having trouble, and We can try parsing the app name out of Heroku remotes, but for the time being the fix is to name sure your app is the none I'll try to tackle this in code before we make a docs change. |
Several reports have matched #72, which was affecting the `restore` command for some users. The cause turned out to be local folder names not matching the name of the Heroku app. Now that Heroku tracks Git remotes, we can take advantage of the Git remote to correctly identify the app name even the local folder name doesn't match. While this requirement has existed for the entirety of Parity's existence, it stopped being a problem for most commands once Heroku introduced remotes. I inadvertently reintroduced this requirement in ad2c21a when we started automatically bypassing confirmation arguments for restores to non-production environments. Fix #72.
|
@eignerchris PR if you want to take a peek to fix the problem. |
Several reports have matched #72, which was affecting the `restore` command for some users. The cause turned out to be local folder names not matching the name of the Heroku app. Now that Heroku tracks Git remotes, we can take advantage of the Git remote to correctly identify the app name even the local folder name doesn't match. While this requirement has existed for the entirety of Parity's existence, it stopped being a problem for most commands once Heroku introduced remotes. I inadvertently reintroduced this requirement in ad2c21a when we started automatically bypassing confirmation arguments for restores to non-production environments. Fix #72.
Several reports have matched #72, which was affecting the `restore` command for some users. The cause turned out to be local folder names not matching the name of the Heroku app. Now that Heroku tracks Git remotes, we can take advantage of the Git remote to correctly identify the app name even the local folder name doesn't match. While this requirement has existed for the entirety of Parity's existence, it stopped being a problem for most commands once Heroku introduced remotes. I inadvertently reintroduced this requirement in ad2c21a when we started automatically bypassing confirmation arguments for restores to non-production environments. Fix #72.
Several reports have matched #72, which was affecting the `restore` command for some users. The cause turned out to be local folder names not matching the name of the Heroku app. Now that Heroku tracks Git remotes, we can take advantage of the Git remote to correctly identify the app name even the local folder name doesn't match. While this requirement has been present for the entirety of Parity's existence, it stopped being a problem for most commands once Heroku introduced remotes. I inadvertently reintroduced this requirement in ad2c21a when we started automatically bypassing confirmation arguments for restores to non-production environments. Fix #72.
Several reports have matched #72, which was affecting the `restore` command for some users. The cause turned out to be local folder names not matching the name of the Heroku app. Now that Heroku tracks Git remotes, we can take advantage of the Git remote to correctly identify the app name even the local folder name doesn't match. While this requirement has been present for the entirety of Parity's existence, it stopped being a problem for most commands once Heroku introduced remotes. I inadvertently reintroduced this requirement in ad2c21a when we started automatically bypassing confirmation arguments for restores to non-production environments. Fix #72.
Several reports have matched #72, which was affecting the `restore` command for some users. The cause turned out to be local folder names not matching the name of the Heroku app. Now that Heroku tracks Git remotes, we can take advantage of the Git remote to correctly identify the app name even the local folder name doesn't match. While this requirement has been present for the entirety of Parity's existence, it stopped being a problem for most commands once Heroku introduced remotes. I inadvertently reintroduced this requirement in ad2c21a when we started automatically bypassing confirmation arguments for restores to non-production environments. I've moved the `git` and `rake` dependencies to the gemspec, as they do not appear to be installed by default if they are listed in the Gemfile. Fix #72.
|
I am still having this exact issue. When I run I am the owner of the heroku apps in question they do not belong to an org. Here are my remotes: |
|
Hi @cantonyselim I haven't pushed v0.9.3 (where the fix is merged) out yet due to a dependency issue. I'm going to leave this ticket open until we do so. |
Anyone else having trouble running
staging restore production? I always receive "App not found".I have origin, production, and staging remotes setup correctly.
The text was updated successfully, but these errors were encountered: