search

buildpacks / lifecycle

Reference implementation of the Cloud Native Buildpacks lifecycle
https://buildpacks.io
Apache License 2.0
187 stars 107 forks source link

Build Process Instrumentation #265

Closed jromero closed 4 years ago

jromero commented 4 years ago

Provide better insight into the events that occur during the build process. This would include event output, outcomes of various commands, performance tracking. This is geared less towards user facing output and more towards generating consumable data.

Raman-Kumar commented 4 years ago

@jromero Can you suggest me some docs or resources to properly understand the codebase of lifecycle and contributing to it?

jromero commented 4 years ago

Hi @Raman-Kumar,

Here are a few resources I was able to put together:

These probably provide a higher-level view of the lifecycle then what you might be asking for. I'm looping in @ekcasey who is a maintainer of the lifecyle and can give you a bit more direct insight into contributing.

Also, @zmackie who originally proposed this story can give you more guidance into the outcomes.

If possible, joining our slack, in particular the #implementation channel, would allow for more direct communication and support.

zmackie commented 4 years ago

@Raman-Kumar Hey! First of this is super exciting. I'd recommend starting to play around with: https://github.com/buildpacks/samples to get an idea of all the components at play as well.

I'll add a bit more details.

zmackie commented 4 years ago

@Raman-Kumar I think there are two ways this work could go, depending on what you're interested in doing:

  1. Expose some way for lifecycle binaries to export profiling information when they're run using something like (https://jvns.ca/blog/2017/09/24/profiling-go-with-pprof/) so that we have built in hooks for future performance work. This could further involve hooking that into pack or working in an RFC or the spec to make profile information hookable for any given platform. I think this is "relatively" straightforward and would be valuable.

  2. Track end-user interactions with pack or the lifecycle so that we can start to understand behavior and improve the tools.

I'm going to speak to the second approach above because its a bit more unclear what that might look like. For the record, I want to be clear about something: this is an exploratory spike to understand how we might go about collecting some metrics around the behavior of the various parts of our application. Collecting such data is a touchy subject and just because we're exploring this doesn't mean we're going to start doing any collection anytime soon. All this work is exploratory. If we do end up deciding to do analytics there will have to be some sort of community conversation around it and it will be an OPT IN thing for users that want to help us improve. Also, this might belong in https://github.com/buildpacks/pack instead of the lifecycle

For the moment, once you get a sense of the architecture of the lifecycle and pack, I'd say take a look at these few links for what we're shooting for:

Raman-Kumar commented 4 years ago

@jromero I have watched the video. Now I am digging into the codebase. @zmackie Now I am understanding the codebase better. Right now I am twisting some code. Soon I will ask some questions. Thanks for the support.

ekcasey commented 4 years ago

I am going to close this spike, let's reintroduce this idea with more tightly scoped issues, or an RFC.