Hey Guys ,

We are using some rest apis to call heroku cli commans as show releases and rolllback, is it possible to call the same way to 'promote' ?

When heroku pipline is run, it has an authentication failure, and asks for re-authentication. When I re-authenticate, it has a failure again and asks for authentication. The next time I run another heroku command it asks for authentication, and it saves it correctly. However if I try heroku pipeline again it de-authenticates.

> heroku apps
=== My Apps
canada-development
django-arbitrage
django-letters
saul

> heroku pipeline:add canada
Authentication failure
Enter your Heroku credentials.
Email: [email protected]
Password (typing will be hidden): 
Authentication successful.
Authentication failure
Enter your Heroku credentials.
Email: [email protected]
Password (typing will be hidden): 
Authentication successful.
Authentication failure
Enter your Heroku credentials.
Email: ^C !    Command cancelled.

> heroku apps
Enter your Heroku credentials.
Email: [email protected]
Password (typing will be hidden): 
=== My Apps
canada-development
django-arbitrage
django-letters
saul

> heroku apps
=== My Apps
canada-development
django-arbitrage
django-letters
saul

Currently we're using the term commit when we should be using release (via @ryanbrainard)

When going from staging to production, there may be unanticipated consequences due to scale. Being able to back down to a previous version quickly and reliably is important. There is no 'revert' or 'demote' command, so this process is going to require preparing and pushing another change upstream, in a potentially complex and stressful situation.
consider adding a command to demote or revert the last production promote
(Issue based on comments from Tantek Çelik)

I've setup heroku pipeline and diff reports that there is one pending commit to. When I attempt to promote, I get the message "APP NAME already exists."

$ heroku pipeline:promote --app myapp-staging
Promoting myapp-staging to myapp-production.... !    myapp-staging already exists.

Pipeline appears to be setup properly:

$ heroku pipeline --app myapp-staging
Pipeline: myapp-staging ---> myapp-production

$ heroku pipeline:diff --app myapp-staging
Comparing myapp-staging to myapp-production...done, myapp-staging ahead by 1 commit:
  4fb94eb  2013-01-19  Add meta description  (Ryan Twomey)

Let me know if you need any more info.

i.e. show Pipeline: fortress-stagign ---> aqueous-fortress-1022 instead of Added downstream app: aqueous-fortress-1022

A lot of times I only get commit SHAs when doing a diff. Looks like this code path is selected. It is not consistent. I'll try to investigate more when I can reproduce it again.

Problem:

• Assets are compiled in the staging environment with staging environment variables
• Upon Pipeline promotion, assets are not recompiled with production environment variables.
• This leads to a fast promotion, but possibly incorrect assets.

Example:

• Rails .js.erb asset file using an ENV variable. Example:

var shareURL = 'https://www.facebook.com/sharer/sharer.php?app_id=12345&u=http%3A%2F%2F<%= ENV['APP_DOMAIN'] %>/r/'+ referral_code.code +'&display=popup&ref=plugin&src=share_button';

Staging:
ENV['APP_DOMAIN'] == 'staging.example.com'

Production:
ENV['APP_DOMAIN'] == 'example.com'

Result:

Production shareURL incorrectly uses 'staging.example.com'

Any advice for situations like this? Can I no longer use Heroku Pipelines?

The JSON lib in heroku-pipelines requires Ruby 1.9.3. This should be loaded by Toolbelt, but there are issues with that. The actual issue is with Toolbelt, but the workaround to just use a different JSON lib that is 1.8.7 is simple enough not to warrant a change in this plugin.

It appears that this usage of rest client does not check proxy settings (unlike the portion within mainline, as seen here: https://github.com/heroku/heroku/blob/cd1cf68ff41dca75071fae1d74caf6138525ca80/lib/heroku/client.rb#L586-L591). We should update as without this, users behind proxy are unable to access pipeline stuff.

User report of git hashes of the promoted app and that sent to the git hook not matching.

Small question is it possible to recompile
automatically the slug during the promotion
(I want to include another dependency, during promotion)

Thanks in advance
Roan

https://github.com/geemus/excon

The documentation produced by the CLI, as well as in the README, claims that pipeline manipulates releases. It doesn't according to our definition of releases.

It appears that the docs and CLI help should be rewritten to use the word "slug" instead of "release"?

The plugin should note that the user doesn't have access to the downstream app, not prompt for credentials.

Other heroku commands run in the context of an upstream app are also prompting for credentials if the user doesn't have access to the downstream app. Presumably there's some check going on for access to the downstream app on every command.

[colin@ayla thesite (master)]$ heroku pipeline:promote
 !    Heroku client internal error.
 !    Search for help at: https://help.heroku.com
 !    Or report a bug at: https://github.com/heroku/heroku/issues/new

    Error:       uninitialized constant Heroku::OkJson (NameError)
    Command:     heroku pipeline:promote
    Plugins:     heroku-pipeline
    Version:     heroku-toolbelt/3.39.5 (x86_64-darwin14) ruby/2.2.2
    Error ID:    58a6420eba27463da414dec94b028aab


    More information in /Users/colin/.heroku/error.log

I recently used OS X's Migration Assistant to initialize a new workstation. This could be an artifact of that.

I attempted to remove and reinstall the pipeline plugin, but it looks like it's not available:

$ heroku plugins:install heroku-pipeline
Installing plugin heroku-pipeline...  ▸    no such package available
 !    error installing plugin heroku-pipeline

heroku pipeline:promote
Comparing deep-thought-1234-staging to deep-thought-1234...done, deep-thought-1234-staging ahead by 1 commit:
  73ab415  2012-01-01  A super important fix  (Joe Developer)

Are you sure you would like to promote these changes? Type target app name to continue:
deep-thought-1234
Promoting deep-thought-1234-staging to deep-thought-1234...done, v2

Also allow optional override with --confirm flag.