project: update target concord version to 2.25.0

[benbroadaway]

walmartlabs/concord#1081 broke opentelemetry when the return type changed for State.getThreadError()

Exception in thread "main" java.lang.NoSuchMethodError: 'java.lang.Exception com.walmartlabs.concord.svm.State.getThreadError(com.walmartlabs.concord.svm.ThreadId)'
        at com.walmartlabs.concord.plugins.opentelemetry.TelemetryCollector.beforeCommand(TelemetryCollector.java:106)
        at com.walmartlabs.concord.svm.ExecutionListenerHolder.fireBeforeCommand(ExecutionListenerHolder.java:43)

[brig]

Is anyone using opentelemetry plugin at Walmart? Just curious :)

We should probably start collecting/exporting some statistics in Concord. like which plugins are used, v1/v2 runtimes, triggers, etc. It would be interesting to see.

If it's some kind of anonymized statistics, maybe even Walmart could export it somewhere :)

[benbroadaway]

Is anyone using opentelemetry plugin at Walmart? Just curious :)

No. I'm toying with some ideas for casting judgement on less-than-well-written flows. Trying to get an idea of how much other stuff we need to drag in/manage to get something like that off the ground. I think the bulk of diagnosis is possible from just process events. The harder part is aggregating it back up to the repo/project/org level (2 gnarly flow executions may not be worth fussing over compared to 10,000 ew-but-could-be-worse flow executions).

We should probably start collecting/exporting some statistics in Concord. like which plugins are used, v1/v2 runtimes, triggers, etc. It would be interesting to see.

If it's some kind of anonymized statistics, maybe even Walmart could export it somewhere :)

I generally agree with the idea. From a custom plugin developer's perspective, it'd be nice to know some metrics about usage. Pumping out live data is probably a stretch to far. But a common dataset of dependency versions and task calls would be useful to reference.