Description
What's the user value of this feature request?
manifest.yml can list a set of buildpacks; but each buildpack can only be listed by either its git url, or its zip URL, or a name if its installed by a platform operator.
This makes it very hard for sample or shared applications, such as https://github.com/starkandwayne/wordpress-for-cloudfoundry, that must provide multiple manifests because they don't know if a target CF will have pre-installed buildpacks or not.
- https://github.com/starkandwayne/wordpress-for-cloudfoundry/blob/master/manifest.yml - manifest with git urls for new buildpack; but these are slow buildpacks since they build libbuildpack bits from source
- https://github.com/starkandwayne/wordpress-for-cloudfoundry/blob/master/manifest.buildpacks.yml - manifest with named buildpacks; but this requires that the user has convinced the platform operator to install the new buildpacks
- another example could be a manifest.yml that has explicit urls to .zip files
Instead, I propose that we change the schema of buildpacks to something like routes - where each item is an object, rather than a simple string; and to allow use to provide all the information about a buildpack:
applications:
- name: wp
buildpacks:
- name: pancake_buildpack
source: https://github.com/starkandwayne/pancake-buildpack
- name: wpcli_buildpack
source: https://github.com/starkandwayne/wpcli-buildpack
- name: php_buildpack Who is the functionality for?
Users of Cloud Foundry
How often will this functionality be used by the user?
Whenever deploying shared applications written by authors who do not know the status of your cf buildpacks list.
Who else is affected by the change?
An implementation could continue to support the existing buildpacks: [pancake_buildpack, php_buildpack] schema.
Is your feature request related to a problem? Please describe.
I don't like that I have to curate multiple manifests and document it in projects like https://github.com/starkandwayne/wordpress-for-cloudfoundry/
I'd prefer that users can get a pre-installed buildpack if it exists; or fallback to a git url if its missing.
Describe the solution you'd like
Support both the existing buildpacks: [name1, name2] and new buildpacks: [{name: name1, source: uri1}, {name: name2}].
Also continue to support name or git url in cf push -b name1 -b url2.
Describe alternatives you've considered
See https://github.com/starkandwayne/wordpress-for-cloudfoundry/ - I must curate multiple manifest.yml for end users and hope they understand the reason for each and when to switch.