Re: Buildpack deep dive questions...

José Riguera López
 

I have a kind of same issue as you trying to understand how a buildpack works and creating a new one. The golang library used in the official buildpacks has no documentation, so it makes really difficult starting from zero, specially if we are talking of something which should be a "helper".
I made a grafana buildpack with bash scripts (https://github.com/SpringerPE/cf-grafana-buildpack) which think it makes easy to understand what each step (the scripts in `bin` folder) are responsible for, and the argument parameters (folders) they get. Is specially important the correct usage of the caching folder to avoid downloading again and again the binaries (resources), because there are other examples on github I think they do not properly manage that part (ofc, the buildpack works but it downloads again and again the resources).

Jose,

El lun., 25 mar. 2019 a las 15:45, Cade Thacker (<cade@...>) escribió:
Long time reader... first time poster :D 

I'm really digging and deconstruction a few different buildpacks trying to understand how they really work.  supply, compile, detect, etc.  Especially the multi buildpack POV. 

So I think i'm starting to get the details straight but I have some basic architecture questions. 

1) For example, if the core functionality of the buildpack is a compiled app (like go or java) and not a scripted language but the github repo only contains the source code then somewhere in this process it must be compiled.  If I want to use the buildpack as an online buildpack that means that the buildpack has to be "built" after it is cloned down during staging.  Is this the correct path?  Or should it be built and the binary pushed back with the code into github? This seems wrong. Somebody hit me with the clue stick. 

2) Second, somewhat tangent question. I know that CloudFoundry is doing tons of work around envoy/istio, but we have a more pressing need right now.  My company has a need to connect many apps and CloudFoundry is just one small part of our runtime. Would it be possible to write a final build pack for envoy and have it basically bind to PORT and then pass the calls to whatever was the 2nd to last buildpack? java, ruby, go, etc.  Forgive me if this is a silly question, but trying to find the edge of this new multi build pack world. Need to inject some custom ingress/egress rules. 

-- 
--cade



--
José Riguera López <jriguera@...>

Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.