Repository navigation
CLI should expose the buildpack being used, especially when -b is used to choose a remote buildpack #311
Description
In this report (and the related tracker bug), the Buildpacks team investigated and learnt that buildpack selection using cf push <appname> -b is maintained between pushes.
This means that if a user selects a broken buildpack, re-pushing does not cause a resolution when an updated admin buildpack is available.
We feel that a UI change would help end users to diagnose this issue more rapidly.
For example, it could work like this:
$ cf push my_app -b https://example.org/broken/buildpack
Creating app my_app in org cf-buildpacks / space development as cf-buildpacks-eng@pivotal.io...
OK
Creating route my_app.cfapps.io...
OK
Binding my_app.cfapps.io to sinatra1234567...
OK
Uploading sinatra1234567...
Uploading app files from: /Users/pivotal/workspace/ruby-issue-26
Uploading 60.6K, 9 files
OK
Starting app sinatra1234567 in org cf-buildpacks / space development as cf-buildpacks-eng@pivotal.io **using remote buildpack https://example.org/broken/buildpack**
OK
[staging stuff happens]
Server error, status code: 400, error code: 170004, message: App staging failed in the buildpack compile phase
$ cf push my_app
Warning: last staging failed using remote buildpack https://example.org/broken/buildpack
To change to an admin-installed buildpack, you must specify one using -b <name_of_buildpack>
[staging stuff happens]
Alternatively, if you were more ambitious, the final output of the cf push could be a table of some kind. Eg:
$ cf push some_app
[snip]
Staging complete.
Information Data Changed since last push
App name some_app No
Route foo.whatever.com No
etc etc yadda yadda No
Buildpack https://example.org/whatever/buildpack No
Activity
cf-gitbot commentedon Dec 9, 2014
We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/84241562.
goehmen commentedon Dec 9, 2014
In this story [0], we changed
cf pushto reflect the actual command push uses. Previous to that, the UX was that some elements of push (like a previous use of -c or -b) would be invoked but not shown to the user. I think this should address your issue in that it would surface to the user that the buildpack specified in the -b is the one being used. The story was accepted last week & is in the edge CLI. It will be in 6.8.0 stable release which will be cut this week.Good?
[0] - https://www.pivotaltracker.com/story/show/79325064
jchesterpivotal commentedon Dec 10, 2014
I think that will help a lot, thanks. I'm closing.