Feature Request: support custom dynamic metrics via ValueSource

[KeyStarr]

In 2.0.9 the issue #454 was fixed - BuildId is now correctly uniquely computed for each build, even over the configuration cache lifespan.

Problem

Some custom metrics might have similar requirements. E.g. suppose, we want to record "free RAM bytes" at the start of the build. If such a custom metric would be implemented currently, it would be incorrectly cached for all builds over the configuration cache lifespan, much like BuildId was before #454.

Solution: allow to define dynamic custom metrics, with values computed during execution phase

Via ValueSource or similarly.

I'd question, though, the importance of such a mechanism. We, for one, are at the very start of integrating Talaiot into our project, and so far we've only needed the "free RAM bytes" dynamic metric. But I can imagine that we might need more later on. It'd be interesting to hear feedback from people who are already Talaiot production veterans.

(extracted as a separate issue as per discussion in #454)

[cdsap]

We’ve just released version 2.1.0, which introduces support for Experimental Provider Metrics: https://github.com/cdsap/Talaiot/releases/tag/v2.1.0

Example usage:

metrics {
    initialProviderMetrics(
        "init_memory_metric" to providers.of(GetMemory::class) {}
    )
}

A few days ago, I had an implementation ready to ship, but after reading your comment, I decided to adjust the approach. Originally, provider metrics were resolved only at the end of the build, but your use case suggested capturing them at the beginning instead. Now, both options are available — you can capture metrics at different points in the build:

initialProviderMetrics(
    "memory_init" to
        providers.of(MemoryCapture::class) {}
)
finalProviderMetrics(
    "memory_end" to
        providers.of(MemoryCapture::class) {}
)

This enables collecting interesting metrics reflecting the build state at two distinct moments.

Additional Notes:

• When using ValueSource in metrics, they are fully compatible with the Configuration Cache.

• Initial metrics are captured when the Build Service is instantiated — this occurs after the configuration cache entry has been loaded. I still need to verify the behavior with large included builds. In the future, we could explore capturing even earlier using a Settings Plugin, but that would require a different approach.

• These new metrics are experimental — you can silence the warning using @OptIn(ExperimentalMetricsApi::class).

As they’re experimental, we have time to collect feedback. Please give them a try and share your thoughts!

[KeyStarr]

Wow, the delivery speed is truly remarkable! Thank you so much, will try this out asap in my project. I'm sorry for such a late response, was absent for awhile.