2.1.0

• [NEW] Support for multiple metric value types
• [NEW] Experimental Provider Metrics

Support for different value types in metrics

Version 2.1.0 adds support for different value types in metrics (e.g., strings and numbers).

Example: Define Metrics with Mixed Type:

customBuildMetrics(
    "a" to "b",
    "c" to 2
)

Resulting Output:

{
  "customProperties": {
    "buildProperties": {
      "a": "b",
      "c": 2
    },
    "taskProperties": {}
  }
}

This change also enables defining your own custom metrics extending Metrics, with support for different value types:

class MyMetric : io.github.cdsap.talaiot.metrics.base.GradleMetric<Long>(
    provider = { 42L },
    assigner = { report, value ->
        report.customProperties.buildProperties["mymetric"] = value
    }
)

Experimental Provider Metrics

Since version 2.1.0, Talaiot includes an experimental mechanism to define metrics using a provider-based system compatible with Configuration Cache.
This approach allows you to lazily evaluate metric values, ensuring that they are resolved only when needed during the build lifecycle.
Two entry points are available for executing these providers:

• Initialization phase – executed at the start of the execution phase.
• Finalization phase – executed once the build has finished.

These APIs (initialProviderMetrics and finalProviderMetrics) are marked as experimental and may change in future versions.
You can suppress the compiler warning by explicitly opting in with @OptIn(ExperimentalMetricsApi::class).

Example:

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

• Fixed: BuildIdMetric behaves incorrectly (#454)

• Fix: 2.0.7 is incompatible with Java 17 #446

• Lazily evaluate TalaiotBuildService parameters when recording finished tasks (#419) by @jamiesanson

• Partial support for Gradle Isolated projects.
• Metrics using ValueSources are retrieved during the publishing phase. Fixes #408

• Removed usage of Provider.forUseAtConfigurationTime method org.gradle.util.NameMatcher #392

• [Talaiot Core] Added type in TaskLength representing the task type [#393]
• [Talaiot Core] New metrics: processMetrics, enabled by default. [#393]
• [Talaiot Core] If processMetrics is enabled, it will include: [#393]
  • gradleJvmArgs: jvm arguments for Gradle processes
  • kotlinJvmArgs: jvm arguments for Kotlin processes
  • processesStats: stats collected at the end of the build for java and kotlin processes. Includes meetrics like Usage, Uptime and GC Time.
• [Talaiot Core]: Remove unused TalaiotBuildService code [#391] thanks wzieba

• [NEW] Differentiate build execution from build duration. New property executionDurationMs in ExecutionReport #383

• [FIX] Parsing module name from path #382

• [FIX] Identify skipped tasks in Build Service #384

• [INFRA] Merge assemble and lint due to strange concurrency limit errors in Circle CI #385

Core Library:

• Remove unused dependencies #375
• Adding Configuration cache hit info #378

Standard/Legacy Plugin:

• Adding InfluxDb2Publisher #377

Internal:

• Fix CI Snapshot publication and move Gradle plugin extension in the plugins 483304e

• Fix wrong initialization of Metrics
• Adding back custom publishers as now are compatible with configuration cache