libcnb-test: testing the `/tmp/libcnb-telemetry` traces

[mars]

When libcnb trace feature is enabled for a buildpack, example Cargo.toml:

[dependencies]
libcnb = { version = "=0.30.2", features = ["trace"] }

…the build process outputs JSONL trace data to /tmp/libcnb-telemetry/.

With libcnb trace feature enabled, could libcnb-test's pack build command be augmented with a --volume argument, like:

--volume ~/cnb-otel:/tmp/libcnb-telemetry:rw

…to provide integration tests a means to verify that the expected telemetry is emitted in that local ~/cnb-otel directory?

[runesoerensen]

@mars This is something I've wanted as well -- the classic .NET buildpack's bin/report implementation depends on the libcnb tracing as well (and I implemented an integration test to test the output).

I've put together a (somewhat rough) draft PR: #985

Rather than exposing the --volume argument directly, this implementation mounts the telemetry directory automatically and provides accessors on TestContext to retrieve the data by buildpack ID and phase:

TestRunner::default().build(&config, |context| {
    let buildpack_id = buildpack_id!("my-org/my-buildpack");

    let detect_telemetry = context
        .detect_telemetry(&buildpack_id)
        .expect("Expected detect telemetry");
    assert_contains!(detect_telemetry, "libcnb-detect");

    let build_telemetry = context
        .build_telemetry(&buildpack_id)
        .expect("Expected build telemetry");
    assert_contains!(build_telemetry, "libcnb-build");
});

The motivation for wrapping the volume mount instead of exposing it is that the current telemetry output path (/tmp/libcnb-telemetry), file naming convention, and collection mechanism are implementation details that could change.

Under the hood it does exactly what you requested though -- a --volume bind mount with :rw -- callers just don't need to manage it.