toggle quoted messageShow quoted text
We could consider exposing on a droplet  the additional metadata that
you've mentioned, such as the buildpack guid for a system buildpack or the
git sha given a buildpack url.
I think it would make sense to consider adding an additional filter to
/v3/droplets to be able to query by creation date. Similarly, allowing
filters based on buildpack information sounds useful as well.
On Sun, Oct 25, 2015 at 2:40 PM, Guillaume Berche <bercheg(a)gmail.com> wrote:
Thanks Mike for the additional details. Long due PR on buildpacks-docs at
Dieu, can you please comment on the suggestion above for more fine grained
buildpack versionning support ?
On Thu, Aug 6, 2015 at 8:02 PM, Mike Dalessio <mdalessio(a)pivotal.io>
I'll let Dieu respond to these suggestions, as she's the CAPI PM.
The /v2/buildpacks endpoint (used by the "cf buildpacks" command)
displays the last update date for a buildpack, e.g.
Would'nt it make sense to have the CC increment a version number for
each update so that it becomes easier to query than only relying on dates
While it's great to have buildpacks provide themselves detailed
versionning info for their code and their most important
dependencies/remote artifacts, I feel the cf platform should provide a bit
more support to help identify versions of buildpacks used by apps, such as:
- refine the app summary endpoint [g2]:
- for system buildpacks: include the buildpack guid (in addition to
the buildpack name) as to allow correlation to /v2/buildpacks endpoint
- for custom buildpacks (url): record and display the git hash
commit for a buildpack url
- refine the app listing endpoints [g4] or v3 [g5] to
- support querying app per system buildpack id
- support querying app by dates of "package_updated_at" or best a
version number as suggested above
I'm wondering whether the CAPI team working on API V3 is planning some
work in this area, and could comment the suggestions above.