3 ms·

I've read through this but I'm not sure I'm seeing any advantages to Buildpack. First point - I see an example of a Dockerfile in TFA, but when it comes to the

I've read through this but I'm not sure I'm seeing any advantages to Buildpack. First point - I see an example of a Dockerfile in TFA, but when it comes to the example of a Buildpack there isn't one; I just see a conceptual description of an abstraction. It appears that a lot of the inference is hidden away by use of 'detection' but is there magic hidden underneath? Does it allow arbitrary hacky steps if needed, like adding a random certificate? Second point - A Dockerfile explicitly codifies what's happening. I can look at it and know how the build will go or what I need to change. The Buildpack equivalent would be spread across many different files, does that sound about right?

codefinger 6y ago
To you first point, there's probably no example of a Buildpack because (unlike Dockerfile) most Buildpack users don't write their own. They are reuseable. I'm not sure why the author didn't include an example of running a buildpack against an app though. To your second point, Buildpacks are written in code too. But unlike Dockerfile, they use real programming languages that you can write tests for. For example: https://github.com/paketo-buildpacks https://github.com/paketo-buildpacks
- speedgoose 6y ago
  Wow, that's a lot of bash boilerplate.
  - codefinger 6y ago
    where?
    - speedgoose 6y ago
      https://github.com/paketo-buildpacks/go/search?l=shell https://github.com/paketo-buildpacks/go/search?l=shell for example. But the situation on many Dockerfile may not be better I have to admit.
      - jacques_chester 6y ago
        These are for Github actions, taken from a shared repo: https://github.com/paketo-buildpacks/github-config https://github.com/paketo-buildpacks/github-config