Should we tell users to update their DNS settings after they have added a new SSL cert (US apps only). A frequent ticket pattern is when customer adds cert, then access site and gets a certificate mismatch. They open a ticket and we tell them they've forgotten to update their DNS to point at the new ELB address.

For example, the default help output is:

Usage: heroku pipelines:create [NAME]

   -s, --stage STAGE   # stage of first app in pipeline
But in reality, the syntax is more like:

Usage: heroku pipelines:create (--app APP | --remote REMOTE) [--stage STAGE] [NAME]

   -a, --app APP   # the Heroku app to use
   -r, --remote REMOTE   # the git remote of the Heroku app to use
   -s, --stage STAGE   # stage of first app in pipeline

When I installed the docker plugin I got the following error:
(running on Mac Yosemite and HomeBrew)
heroku plugins:install heroku-docker Installing Heroku Toolbelt v4... done. For more information on Toolbelt v4: https://github.com/heroku/heroku-cli Setting up node-v4.2.1... done Installing core plugins heroku-cli-addons, heroku-apps, heroku-fork, heroku-git, heroku-local, heroku-run, heroku-status... done Installing plugin heroku-docker... Error reading plugin: jasmine-reporters. See /Users/username/.heroku/error.log for more information.
npm install -g jasmine-reports
npm install -g jasmine-reporters and re-running the heroku-docker install solved the problem.

When running heroku without any arguments, it tries to install it everytime I run it. When running a subcommand like heroku appsinfo, it actually tries to run twice, and --version seems to install 3 times:

$ heroku
Installing core plugins heroku-local, heroku-status...
 ▸
Usage: heroku COMMAND [--app APP] [command-specific-options]


$ heroku apps:info
Installing core plugins heroku-local, heroku-status...
 ▸
Installing core plugins heroku-local, heroku-status...
 ▸    

$ heroku --version
Installing core plugins heroku-local, heroku-status...
 ▸    
heroku-toolbelt/3.42.16 (x86_64-darwin13.0) ruby/2.1.1
Installing core plugins heroku-local, heroku-status...
 ▸    
heroku-cli/4.25.2-beb750a (amd64-darwin) go1.5.1
Installing core plugins heroku-local, heroku-status...
 ▸    
=== Installed Plugins
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
manager-cli

Currently heroku login prompts for email and password. To do that, I need to flip to my password manager and get at least my password, if not my email as well for convenience.

It would be very nice if instead heroku login did a normal web-based OAuth flow so, if I get prompted for email and password by id.heroku.com or similar, I can just use my password manager as I do for the web normally.

STR:

$ cloud staging
HEROKU_CLOUD => staging
ION_HOST => ion-staging.herokai.com
HEROKU_HOST => staging.herokudev.com
HEROKU_API_URL => https://api.staging.herokudev.com
HEROKU_APPDOMAIN => staging.herokuappdev.com

$ heroku auth:whoami
 ▸    Get https://api.staging.herokudev.com/account: x509: certificate signed by unknown authority

Expected outcome: my current login information, as relevant to staging.

Actual outcome: SSL certificate signing error shown above.

Attempted workaround:

$ HEROKU_SSL_VERIFY=disable heroku auth:whoami
 ▸    Get https://api.staging.herokudev.com/account: x509: certificate signed by unknown authority

$ HEROKU_SSL_VERIFY=false heroku auth:whoami
 ▸    Get https://api.staging.herokudev.com/account: x509: certificate signed by unknown authority

The old pgbackups url command gave the raw url, and it was very scripting friendly.
The new output has the annoying text:

The following URL will expire at 2015-04-05 22:38:55 +0000:
https:....

This isn't scripting friendly, can you provide a form where it outputs the raw url? or make the default behavior the same as the old one?

The ruby toolbelt will use netrc.gpg if it exists with help from the netrc gem. For new JS-based plugins, such as heroku-git, ~/.netrc.gpg is not respected.

--app is an option to Heroku's toolbelt for the logs command, but by standard CLI design, it should be allowed before or after the root command, right?

$ heroku --app random-app logs -t
!    `--app` is not a heroku command.

Commands like heroku git help should display the help for the git topic. Doing this in a way that will also support things like heroku git:remote -a help might be tricky though.

heroku used to work in the older version with HEROKU_API_KEY variable set only, but current version will complain if it can't find netrc file.

I understand that heroku (toolbelt) is thought for end users mainly, but we're using it as a part of our system (as a dependency) to run commands on heroku on users' behalf, and I don't see a way to do that anymore.

Any plans to "fix" this please?

/cc: @as-cii

I find the behavior of running an upgrade process prior to executing the command I've specified troubling.

The last thing I want when running a system command (especially if it is a time-critical / production command) is an arbitrary update process blocking it. What if the upgrade process fails? Is my CLI crippled at a critical moment?

I understand that keeping users up-to-date on the toolbelt benefits everyone in terms of security, but I depend on the CLI tool executing in a predictable manner.

If I understand correctly, v3 is written in Ruby, whereas v4 is written in Go. Using Go allows you to ship a self-contained binary, without the dependency on Ruby. This seems like a good thing.

But v4 also uses Node. Presumably to avoid having a dependency on a system-wide installation of Node, v4 installs its own copy of Node into .heroku. To do this, it downloads a binary release of io.js from https://iojs.org/dist - see nodeURL() in gode/client.go

This uses runtime.GOOS to determine which release to download. That's fine if there is a binary release for your platform: so Linux, Windows and OS X are OK. But it doesn't work if there isn't an io.js binary release for your operating system.

Here's the result on OpenBSD:

$ ~/.heroku/heroku-cli
Setting up iojs-v3.2.0... ▸    gzip: invalid header

On OpenBSD, runtime.GOOS is openbsd. So nodeURL() will return https://iojs.org/dist/v3.2.0/iojs-v3.2.0-openbsd-x64.tar.gz - which does not exist.

You ought to get a 404 when you try to download it. But it looks like you're then trying to pass the non-existent file to gzip.

So this won't work on FreeBSD, OpenBSD or any other OS that doesn't have a binary io.js release available for it. That's a shame, as v3 of the Heroku CLI always used to work well on them.

At the least, a better error message would be good. Preferably, we either wouldn't need a Node installation at all or we could use a system-wide installation rather than a sandbox in .heroku. I understand why you don't want a dependency on a system-wide installation - but if you're going to use Node (rather than doing everything in Go) then you've got that dependency anyway. Surely it's better to allow use of a system-wide installation than not to work at all?

What is Node (or io.js) used for? I can't actually see any JavaScript in this repo yet. It all seems to be Go.

As the title = =, what should I do?
the operation system is windows 10

We use heroku toolbelt from our deployment scripts to great effect, but wind up having a bunch of code to parse its output. Since the tool is ever evolving this means that we have to play catchup when things change. It would be incredibly useful if there was an option to get structured output from running toolbelt so that instead of:

$ heroku apps
=== My Apps
foo-1
foo-2

=== Collaborated Apps
bar-1
bar-2

We could get (eg) easily parseable JSON

$ heroku apps --type=json
{ "apps": ["foo-1", "bar-1"], "collaborated": ["bar-1", "bar-2"] }

There are other API clients we can use, but this CLI seems to be the most up to date as Heroku evolves. Are there any plans to move in this direction in the v4 client?

When I type "heroku maintenance:on -a myapp", I got
Installing Heroku Toolbelt v4... done
▸ rename /home/jcl/.heroku/tmp/node071638888/iojs-v2.3.2-linux-ia32 /home/jcl/.heroku/iojs-v2.3.2-linux-ia32: no such file or directory
▸ rename /home/jcl/.heroku/tmp/node064785859/iojs-v2.3.2-linux-ia32 /home/jcl/.heroku/iojs-v2.3.2-linux-ia32: no such file or directory
▸ rename /home/jcl/.heroku/tmp/node055304210/iojs-v2.3.2-linux-ia32 /home/jcl/.heroku/iojs-v2.3.2-linux-ia32: no such file or directory

and then get the prompt. The status of the app is unchanged.

Looking for similar difficulties, I tried "heroku update" but then got
▸ rename /home/jcl/.heroku/tmp/node104973427/iojs-v2.3.2-linux-ia32 /home/jcl/.heroku/iojs-v2.3.2-linux-ia32: no such file or directory
error loading plugin commands
! To update this version of the Heroku client please use
! apt-get install heroku-toolbelt

apt-get install heroku-toolbelt told me I already have the last version.

I run heroku on a Ubuntu 12-04-5 LTS release. And updates are done.

I had the heroku-toolbelt installed on my raspberry pi. With the new v4 release of the heroku-toolbelt it started to fail and I had to reinstall it:

wget -O- https://toolbelt.heroku.com/install-ubuntu.sh | sh
Now when checking the installation it looks heroku is under the right path:

$ which heroku /usr/local/heroku/bin/heroku
But when running any heroku commands it tries to update itself and fails:

$ heroku --version
Installing Heroku Toolbelt v4... done.
For more information on Toolbelt v4: https://github.com/heroku/heroku-cli
Illegal instruction
Illegal instruction
! error getting commands pid 3275 exit 132

Note: I am under Raspbian GNU/Linux 7 (wheezy)

Using Windows 7 Ultimate SP1
From cmd using heroku or heroku update terminal hangs. See image below.

What I have tried.

• Deleted the folders Username/.heroku , and Username/AppData/Local/heroku. Same hang spot.
• Did above plus uninstalled heroku toolbelt downloaded newest tool belt from heroku and installed. Same hang spot.
• Did everything above plus uninstalled/deleted anything that seemed to be heroku app related. Same hange spot.

Any suggestions?

Thanks,

Casey

This is now fixed. Just update your CLI.

Just run the following

$ heroku update
$ heroku login
OR
$ winpty heroku login -i

Or use cmd.exe instead

When I run heroku, I see the following message:

$ heroku
heroku-cli: Installing core plugins...
 ▸    Error installing package. 
 ▸    
 ▸    Try running again with GODE_DEBUG=info to see more output.

I tried running $ GODE_DEBUG=info heroku to see more output, but it had no effect.

So far, this error appears to be benign for my use cases.

I am running heroku-toolbelt 3.42.21 on NixOS 15.09:

$ heroku --version
heroku-cli: Installing core plugins...
 ▸    Error installing package. 
 ▸    
 ▸    Try running again with GODE_DEBUG=info to see more output.
heroku-toolbelt/3.42.21 (i686-linux) ruby/2.2.2
heroku-cli: Installing core plugins...
 ▸    Error installing package. 
 ▸    
 ▸    Try running again with GODE_DEBUG=info to see more output.
heroku-cli/4.27.2-eb1b3ca (386-linux) go1.5.1
heroku-cli: Installing core plugins...
 ▸    Error installing package. 
 ▸    
 ▸    Try running again with GODE_DEBUG=info to see more output.
You have no installed plugins.

rm -rf ~/.heroku
sudo heroku buildpacks # does an install into ~ as root, now everything is messed up

This would also be a problem if we updated node packages automatically. Need to think about how to keep this runnable as the root user as well. We need to make sure .heroku is owned by the proper user at all times.

 -o, --org ORG     # the org to list the apps for
 -A, --all         # list all collaborated apps, including joined org apps in personal app list
 -p, --personal    # list apps in personal account when a default org is set

My impression is that -A should list all the apps including any "joined org apps". I'm not sure what it means by "personal app list". I've tried everything to get them to show up - favoriting, changing permissions in the org, etc. but they are not listed unless I explicitly ask for heroku apps -o myorg.

Any of these:

[andrew@mbp ~/git/project]$ heroku apps -p -A
[andrew@mbp ~/git/project]$ heroku apps -p
[andrew@mbp ~/git/project]$ heroku apps

Only returns:

=== My Apps
personal-project
prototype
other-thing

=== Collaborated Apps
friend-project         [email protected]
other-project          [email protected]

Whereas this:

[andrew@mbp ~/git/project]$ heroku apps -p -A -o myorg

Returns only this:

=== Apps in organization myorg
company-project
client-project
space-program

Using the undocumented needsApp: true and variableArgs:true I'd expect the -a appname to be stripped from context.args so my plugin doesn't have to deal with them. Currently, -a appname is still in context.args.

The cli should allow short flags to be used together:

$ heroku apps:info -sa appname

After the toolkit upgrade the heroku git:remote -a app command does not consider the HEROKU_HOST variable and add the remote for the official host instead of the devcloud:

☁ rodrigo  heroku git:remote -a
 chama
Installing Heroku Toolbelt v4... done
updating plugins... done
Installing plugin heroku-git... done
set git remote heroku to https://git.heroku.com/chama.git

Console tools installed via packaging system must not behave in such manner. Simply because node.js is available via the very same packaging system.

P.S.
Which latest version of heroku doesn't require node.js I'd like to keep up with ruby version.

https://gist.github.com/hunterloftis/f66a15e142828027dbf9

--foo bar works but --foo=bar doesn't.

It seems that heroku local is swallowing some console output. Here is a Stackoverflow post that describes the problem in detail.

I've seen this too. Only tried with JVM processes though.

Every time I try a heroku command it seems Toolbelt tries to update itself but it fails when renaming node.exe, a file that already exists in the %HOME%/.heroku dir.

similar to https://github.com/daneharrigan/heroku-alias but it might be better to use ~/.herokurc

Not sure if this is considered an error or not, but config:get now returns undefined instead of the empty string if a config property does not exist. It broke some of our build scripts which expected the empty string. Maybe it's our fault for writing poor scripts, but it did surprise us.
We've fixed our scripts to handle either, so you may close if you feel this was an expected change.

$ heroku config:get SOME_PROP -a app-name
undefined

cc @ransombriggs

my client just updated and I noticed the following no longer functions:

$ heroku auth:token                                                                                                                                             [18:00:07]
 !    Resource not found

when you add --help to a default topic command, it doesn't show the other commands under the topic

The error message that gets printed if the user passes an invalid app name isn't very helpful. I'd expect this to be handled before my plugin is run.

> h loco:run python manage.py something -a no-such-app
/Users/msibson/heroku/loco-plugin/lib/commands/run.js:22
      if (err) { throw err; }
                       ^
Error: Expected response to be successful, got 404
    at Request.handleFailure (/Users/msibson/heroku/loco-plugin/node_modules/heroku-client/lib/request.js:258:9)
    at ConcatStream.directResponse [as cb] (/Users/msibson/heroku/loco-plugin/node_modules/heroku-client/lib/request.js:167:12)
    at ConcatStream.end (/Users/msibson/heroku/loco-plugin/node_modules/heroku-client/node_modules/concat-stream/index.js:44:21)
    at IncomingMessage.onend (_stream_readable.js:489:10)
    at IncomingMessage.g (events.js:257:16)
    at emitNone (events.js:72:20)
    at IncomingMessage.emit (events.js:163:7)
    at _stream_readable.js:891:16
    at process._tickCallback (node.js:339:13)

When I type heroku it hangs after

2015/10/30 00:56:32 running from C:\Users\Zhichao\AppData\Local/heroku/heroku-cli.exe
2015/10/30 00:56:33 Setting up node-v4.2.1...
2015/10/30 00:56:44 done
2015/10/30 00:56:44 Installing core plugins heroku-cli-addons, heroku-apps, heroku-fork, heroku-git, heroku-local, heroku-run, heroku-status...

indefinitely. I took that out of the error.log in my AppData. If i ctrl-c and then run it again, that message is followed by

2015/10/30 01:01:01 not supported by windows
2015/10/30 01:01:01 not supported by windows
2015/10/30 01:01:01 not supported by windows
2015/10/30 01:01:01 not supported by windows
2015/10/30 01:01:01 not supported by windows
2015/10/30 01:01:01 not supported by windows
2015/10/30 01:01:01 not supported by windows

I've tried a lot of stuff, including deleting the appdata heroku folder, reinstalling. Any help would be greatly appreciated.

This repository has no LICENSE file, so it's not clear how it can be used.

I'd like to make a change to the confirmation message that is displayed when a user calls certs:remove.

I'd like to update the message to (added 3rd line):

 !    WARNING: Potentially Destructive Action

 !    This command will remove the endpoint YYYY.herokussl.com from XXXX.

 !    This action cannot be rolled back using certs:rollback.

 !    To proceed, type "XXXX" or re-run this command with --confirm XXXX

I believe this is just a documentation issue. The example given when you type heroku help addons says:

$ heroku help addons
Usage: heroku addons [{--all,--app APP_NAME,--resource ADDON_NAME}]

 list installed add-ons

 NOTE: --all is the default unless in an application repository directory, in
 which case --all is inferred.

 --all                  # list add-ons across all apps in account
 --app APP_NAME         # list add-ons associated with a given app
 --resource ADDON_NAME  # view details about add-on and all of its attachments

Examples:

 $ heroku addons --all
 $ heroku addons --app acme-inc-website
 $ heroku addons --resource @acme-inc-database

Additional commands, type "heroku help COMMAND" for more details:

  addons:_create                                  #
  addons:attach ADDON_NAME                        #  attach add-on resource to an app
  addons:create                                   #
  addons:destroy ADDON_NAME [ADDON_NAME ...]      #  destroy add-on resources
  addons:detach ATTACHMENT_NAME                   #  detach add-on resource from an app
  addons:docs ADDON_NAME                          #  open an add-on's documentation in your browser
  addons:downgrade ADDON_NAME ADDON_SERVICE:PLAN  #  downgrade an existing add-on resource to PLAN
  addons:info ADDON                               #  Show info about an add-on and its attachments.
  addons:open ADDON_NAME                          #  open an add-on's dashboard in your browser
  addons:plans SERVICE                            #  list all available plans for an add-on service
  addons:services                                 #  list all available add-on services
  addons:upgrade ADDON_NAME ADDON_SERVICE:PLAN    #  upgrade an existing add-on resource to PLAN

But using the --resource flag doesn't appear to work.

Reproduce:

Add an entry like:

machine github.com
  login foo
  password x-oauth-token
  protocol https

Currently complains with:

Error parsing netrc at /home/cyx/.netrc
line 47: keyword expected; got protocol

likely need to fix this by using a different directory

Hi,

Is it possible to keep the .git folder when deploying to Heroku? We need to do some processing based on the data in this folder.

heroku/legacy-cli#1509

Thanks!

for example, heroku-sso needs to be

Hi!
We have a CI chain that setups heroku toolbelt as administrator (on Windows OS).

Later on, CI users with no admin privileges uses heroku that tries to auto update itself and fails:

heroku apps:info --app appName 

For more information on Toolbelt v4: https://github.com/heroku/heroku-cli
Setting up node-v4.1.0... â–¸    rename D:\Windows\system32\config\systemprofile\.heroku\tmp\download695155819\file D:\Windows\system32\config\systemprofile\.heroku\node-v4.1.0-windows-x86\bin\node.exe: Access is denied.
error loading plugin commands
error loading plugin topics
error loading plugin commands
 !    `apps:info` is not a heroku command.
 !    Perhaps you meant `labs:info` or `pg:info`.
 !    See `heroku help` for a list of available commands.

Two questions about this:

1. If heroku-cli autoupdates per user (at it seems to be), should it have a full installation into users apps folder space (users\appdata) and not in a central place like D:\Windows\system32\config\systemprofile ?
2. Is there a way to disable auto-update to work-around this? Asumming only admin will auto-update it.

Happens on Windows OS with heroku version:

heroku --version

heroku/toolbelt/3.42.3 (i386-mingw32) ruby/1.9.3
heroku-cli/4.23.3-59548ea (386-windows) go1.5.1
=== Installed Plugins
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

When trying to install the Heroku CLI in a docker container, it seems to hang at:

Installing Heroku Toolbelt v4... done.
For more information on Toolbelt v4: https://github.com/heroku/heroku-cli
heroku-cli: Adding dependencies... done
heroku-cli: Installing core plugins...

Indefinitely. Using an ubuntu:14.04 base image and installing with:

RUN wget -O- https://toolbelt.heroku.com/install-ubuntu.sh | sh \
  && heroku plugins:install heroku-docker

Any ideas?

My docker file looks like:

FROM ubuntu:14.04
RUN apt-get update -y && apt-get install -y wget
RUN wget -O- https://toolbelt.heroku.com/install-ubuntu.sh | sh \
  && heroku plugins:install heroku-docker

I'm running this within another docker container in our CI environment (Buildkite).

The code currently expects stty to be in /bin/stty. This is not always the case (e.g. in NixOS, it's in /run/current-system/sw/bin/stty), which can lead to the following error on login:

Password (typing will be hidden): 
 ▸    failed turning off console echo for password entry:
 ▸      no such file or directory

I have separate SSH identities for personal and work Heroku accounts.

The following used to work:

> git config -l
...
[email protected]:storyworth.git
remote.production.fetch=+refs/heads/*:refs/remotes/production/*
heroku.remote=production
...

> heroku info
 ▸    could not find app name in production git remote

It seems like appNameFromGitURL in git.go no longer correctly parses the app name from the git url [email protected]:storyworth.git

Based on the code, I may be able to set a HEROKU_GIT_HOST environment variable to heroku.work, but that won't work on a per-app basis, and this used to work seamlessly.

$ wget -qO- https://toolbelt.heroku.com/install.sh | sh
This script requires superuser access to install software.
You will be prompted for your password by sudo.
Add the Heroku CLI to your PATH using:
$ echo 'PATH="/usr/local/heroku/bin:$PATH"' >> ~/.profile
$ . ~/.profile
$ heroku --help
Installing Heroku Toolbelt v4... done.
For more information on Toolbelt v4: https://github.com/heroku/heroku-cli
Setting up node-v4.2.1... ▸ rename /tmp/node563078790/node-v4.2.1-linux-x86 /home/terence/.heroku/node-v4.2.1-linux-x86: invalid cross-device link
done
Setting up node-v4.2.1... ▸ rename /tmp/node923094573/node-v4.2.1-linux-x86 /home/terence/.heroku/node-v4.2.1-linux-x86: invalid cross-device link
Setting up node-v4.2.1... ▸ rename /tmp/node415232141/node-v4.2.1-linux-x86 /home/terence/.heroku/node-v4.2.1-linux-x86: invalid cross-device link
! error getting commands pid 10247 exit 1

My /tmp is mounted tmpfs:
tmpfs on /tmp type tmpfs (rw,seclabel)
But I think it is common in modern linux OS.