fix: apps:rename and apps:destroy incorrectly handles git remotes

[justinwilaby]

fixes #3109

To test

1. Add 1 or more remotes that point to the same app. e.g. heroku git:remote APP_NAME && heroku git:remote APP_NAME --remote heroku-dev` - This will add 2 remotes
2. Verify heroku and heroku-dev exist and they both point to the same URL
3. Run ./bin/run apps:rename -a OLD_APP_NAME NEW_APP_NAME with the cwd of your local git repo.
4. Verify both remotes have changed git remote -v

[eablack]

i tested this and am still getting an error when i try to rename. first tried with two remotes and then with three:

[justinwilaby]

i tested this and am still getting an error when i try to rename. first tried with two remotes and then with three:

My apologies @eablack - In this case the -a flag is needed which I unintentionally omitted in the test instructions. Please try again with the updated instructions.

[eablack]

Works great! The only thing I wonder about is whether we should have this explicitly tested. It's kind of a side effect of the command, though, so I'll leave it to your discretion if you think there's a valuable way to add a test for this.

[jmasson]

My apologies @eablack - In this case the -a flag is needed which I unintentionally omitted in the test instructions. Please try again with the updated instructions.

@justinwilaby I was playing with this today and found if I'm inside my apps git repository, and have a heroku remote, I can run heroku apps:rename new-example-app without -a, and so still get the behaviour of the remote being deleted. If I don't have a remote, it does give the Missing required flag app error.

I wonder if -a should be required, even when you have a single heroku remote, if that's the only way to ensure the renaming happens? CLI help does already say that it is: (-a, --app=<value> (required) app to run command against) but seems not in this circumstance (similar to heroku apps:info, etc).

I guess even nicer would be if it renamed it without -a in circumstances where that is allowed (I assume when there is only one remote?).

[sbosio]

I'll be providing an answer here, but we should continue the discussion on the issue that was created to follow this, given this PR is already closed and merged. I will post this answer there too.

Hi @jmasson, the behavior you described is just how the Heroku CLI operates to determine the target app for any command requiring the --app value to be provided.

When the --app option is required for any command but you don't explicitly provide that value on the command line, Heroku CLI will attempt to auto-detect it from the Git remotes configured only if you happen to be inside a local Git repository with a single remote targeting a Heroku Git host. If it founds a single remote configured, then the target app name will be set by default.

I.e. a command like the one you described: heroku apps:rename new-example-app it's expected to work if you were inside a local Git repo with a single Heroku remote configured (e.g. heroku https://git.heroku.com/old-example-app.git) and after the command runs, the old remote should've been removed and re-targeted at heroku https://git.heroku.com/new-example-app.git. Is that the behavior you observed or were there any issues renaming the app or re-targeting the Git remote to the new app name?