libcnb debugging experience (running against a SHA or branch)

[schneems]

Here's one method described here #6 (reply in thread). Classic buildpacks can use branches on Heroku. While I think it's great there's a way to run branches locally, I'm thinking that we will also want the ability to run/test branches on Heroku (or maybe you disagree, it's a discussion!). To that end here's some options:

Local only, build Rust cnbs

• Document a set of steps similar to What is your Heroku Cloud Native Buildpacks Experience? #6 (reply in thread).
  • Allows people to test/run locally. It's technically possible
  • Anyone who wants to test code needs to have a rust development environment setup. It's a several step-hoop to jump through
  • With a two part "build the buildpack" and separate "build the app" it's easy to miss a step and possibly be using an old/different build than previously thought (for example if you forget to build the buildpack and are using an older build).
  • Cannot run debug builds on Heroku (when eventually you'll be able to deploy CNBs to Heroku)

Bootstrap script

• Introduce a bin/build and bin/detect script into each buildpack that will first build/bootstrap the buildpack.
  • Easier to debug locally
  • Allows debug execution on Heroku (when supported)
  • Downside: People sometimes stick/lock to older SHAs. Making it easier to do it makes it easier for them to do the wrong thing.
  • Downside: Complexity introduced. Do we need to optimize this experience like caching and not re-building if previously built?

Something else?

• Make a custom extension in Kodon that detects and compiles rust CNBs when no bin/build found
• Upstream support for a bin/bootstrap perhaps? (But I'm not sure what that buys us unless we could use CNBs to build CNBs and THAT would be awesome).
• What does paketo do here? IDK

[edmorley]

I agree we should constantly be on the look out for ways to make the development/contribution/testing/debugging experience easier, however, I don't think we should try and add full on support to our tooling for day to day branch based buildpack usage by end users. Users should be encouraged to be on the latest version of the buildpack, plus IMO we should get in the habit of more frequent (and smaller, bite-sized) releases (which will be easier with our release automation), plus things like feature flags for experimental features.

I also think that #6 (reply in thread) is potentially a bit of a red herring (or at least a less common edge case), since:

• Adding support for a brand new stack and multi-arch is a fairly complex change, and not one that we would normally expect end users to try and work through themselves (vs a random "add a buildpack feature PR" scenario). Ideally in the future we'll have support added for a new stack sooner (which will be a lot easier given we'll already have multi-arch support next time), and so users not need to come up with workarounds themselves.
• Many of the hiccups encountered in that thread were less about the Rust compilation side, and more about the new stack/multi-arch/build plan things that are orthogonal to Rust compilation.

That said, there are some things we can do to improve the contribution experience, such as:

1. Setting up the GitHub devcontainers feature on each of our CNB repos - which means users won't need to figure out installing Rust etc: https://docs.github.com/en/codespaces/setting-up-your-project-for-codespaces/adding-a-dev-container-configuration/introduction-to-dev-containers
2. Improving upstream libcnb.rs setup guides, docs and error messages.
3. Making sure each of our CNB's README.md or CONTRIBUTING.md explains how to build the CNB (with links to the upstream libcnb.rs docs, so we don't duplicate/have stale docs)
4. Implementing Add a cargo command for performing both packaging and a pack build libcnb.rs#484

• With a two part "build the buildpack" and separate "build the app" it's easy to miss a step and possibly be using an old/different build than previously thought (for example if you forget to build the buildpack and are using an older build).

Agree. I think (4) above would resolve this? :-)

Make a custom extension in Kodon that detects and compiles rust CNBs when no bin/build found

I think as a general rule of thumb we should not consider Kodon-only solutions for most problems, since it breaks the whole "it works locally the same as on Heroku" paradigm. (Plus means we have to maintain something inside another team's component, which is also harder for us to test, since running a whole Kodon instance locally is non-trivial.)

(But I'm not sure what that buys us unless we could use CNBs to build CNBs and THAT would be awesome).

The concept of CNBs building CNBs has come up before - IMO it does not make any sense. CNBs are for building final OCI images for applications, with concepts like lifecycle, launcher, layers, base images, rebase etc. For example, a buildpack release does not want/need a launcher binary or the contents of a base image inside the buildpack, has no need for layers, rebase etc. The .cnb and OCI image methods of packaging buildpacks are ultimately just an equivalent of gzipping up buildpack.toml and couple of binaries, so more akin to releasing a software tool/library package than creating an full application OS image.