I think this must have been related to the 3.0.0 release, but this command no longer works:

$ make start
heroku local:run ./node_modules/.bin/nodemon --ignore ./lib ./bin/api

  error: unknown option `--ignore'

run is getting tripped up by the flags passed to nodemon. And using -- doesn't seem to work to delimit flags either.

If I try to heroku run on a new app with a dyno running, I get an error about Free dyno limits, but no indication on how to fix it:

maciek@mothra:~/code/aux/newts-poc$ heroku run init
Running init on newts-testing... !!!
 ▸    Cannot run more than 1 Free size dynos.

It'd be great if this could link to the dyno type documentation or generally give more hints as to how to resolve the issue.

This used to work:

$ heroku logs -ta myapp

now it does not:

$ heroku logs -ta myapp
 ▸    -t, --tail does not take a value

Originally reported here: heroku/dogwood#635

heroku run --example -a $APP will send --example as the command to be run.

heroku-cli/6.15.5-1f03166 (darwin-x64) node-v9.3.0

Plugin heroku-run is updating...
Plugin heroku-run is updating... ⣷
Plugin heroku-run is updating... ⣽

Running bash on ⬢ foo-bar ... up, web.1 (undefined)

The problem is that we use dyno.size but it is not defined for the run inside endpoint that we hit, we either need to add to the serializer in API or pull in the CLI.

https://github.com/heroku/heroku-run/blob/master/lib/dyno.js#L93

When ever I call the run command passing in -x (or --exit-code). It appears to add a semicolon which does not seem to be parsed correctly over in the dyno.

Getting:

heroku run -x -a myApp --type=worker -- node test.js
Running node test.js on ⬢ MyApp... up, worker.3465 (Private-M)
 ▸    Warning: Dynos can take up to a few minutes to be provisioned in Private Spaces.
module.js:549
    throw err;
    ^

Error: Cannot find module '/home/test.js;'
    at Function.Module._resolveFilename (module.js:547:15)
    at Function.Module._load (module.js:474:25)
    at Function.Module.runMain (module.js:693:10)
    at startup (bootstrap_node.js:191:16)
    at bootstrap_node.js:612:3
 ▸    No exit code returned

Or even better:

heroku run -x -a myApp --type=worker bash                                   
Running bash on ⬢ myApp... up, worker.6364 (Private-M)
 ▸    Warning: Dynos can take up to a few minutes to be provisioned in Private Spaces.
FATA exec: "bash;": executable file not found in $PATH 
 ▸    No exit code returned

@dickeyxxx When I was reviewing #9 I noticed a bug in the buildCommand method here

-> % heroku run echo 'foo " bar'
--> POST /apps/app/dynos
--> {"command":"echo \"foo \" bar\"","attach":true,"env":{"TERM":"xterm-256color","COLUMNS":157,"LINES":81}}
Running echo "foo " bar" on app... <-- 201 Created
<-- 
up, run.2196
bash: -c: line 0: unexpected EOF while looking for matching `"'
bash: -c: line 1: syntax error: unexpected end of file

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

The push permission to the Git repository is required.

semantic-release cannot push the version tag to the branch master on remote Git repository.

Please refer to the authentication configuration documentation to configure the Git credentials on your CI environment.

Good luck with your project ✨

Your semantic-release bot 📦🚀

It seems that ssh transmit doesn't have the code to detect the exit code like rendezvous does. This results the run -x command failing to capture the exit status (〓 is substituted for \uFFFF):

Private Spaces app

$ heroku run -x -a daigo-dango-tokyo false; echo $?
Running false on ⬢ daigo-dango-tokyo... provisioning, run.6499 (Private-M)
 ▸    Warning: Dynos can take up to a few minutes to be provisioned in Private
 ▸    Spaces.
〓 heroku-command-exit-status 1
0

Common Runtime app

$ heroku run -x -a daigo-dango false; echo $?
Running false on ⬢ daigo-dango... up, run.8789 (Hobby)
 ▸    Process exited with code 1
1

... with attached dynos, here.

IIRC the original CLI command used to do that, and only print up <dyno.name> after the rendezvous dance is done, which means the dyno is really running.

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

The push permission to the Git repository is required.

semantic-release cannot push the version tag to the branch master on remote Git repository.

Please refer to the authentication configuration documentation to configure the Git credentials on your CI environment.

Good luck with your project ✨

Your semantic-release bot 📦🚀

If the dyno crashes before it can be attached, heroku run hangs waiting for attachment that never happens.

Steps to Reproduce:

1. Create a bad slug (e.g. put some crap in file, but not in tgz format)
2. Create a release from the slug
3. Launch a one-off with the slug. Hangs like this:

$ heroku run bash -a app-crash
Running bash on ⬢ app-crash... ⢿ connecting, run.2057

If you look in the logs, you can see it immediately completed (i.e. crashed):

2016-08-16T23:49:09.524773+00:00 heroku[api]: Starting process with command `bash` by [email protected]
2016-08-16T23:49:09.890177+00:00 heroku[run.2057]: State changed from starting to complete

I suggest that we poll in the background for the dyno status and error out early if the dyno is gone. A simple timeout on the connect would probably not work because of Private Space boot times, and we'd want this to fail faster than that.

All cases I tried are done with a Symfony2 PHP project. To reproduce it, you can deploy this demo app: https://github.com/dzuelke/symfony-standard-heroku
The app/console file is an executable PHP script with a shebang to find the PHP executable.

heroku run 'app/console' works fine with and without the --exit-code option.
However, using a command with arguments breaks when using the plugin:

heroku run 'app/console list' works fine, while heroku run 'app/console list' --exit-code will break.

Note that the heroku-exit-status for the v3 handled this (before it stopped working because of changes in the heroku CLI): https://github.com/glenngillen/heroku-exit-status

h run:inside -a retrodot-production rails c
Running c on ⬢ retrodot-production... !
 ▸    rails must be "up" before you can use run:inside. Please try again later.

My error here was in failing to specify a dyno to run inside. It interpreted "rails" as a dyno name. It looks like it's telling me "rails isn't up", which almost makes me think my production app is down or something! Kind of scary for a user.

I'm thinking a clearer error here would be something like: "rails" isn't the name of a running dyno in this app or "rails" isn't a dyno type in this app.