Skip to content

ci(coverage): merge per-integration coverage in All Green before upload#9086

Merged
BridgeAR merged 5 commits into
masterfrom
BridgeAR/2026-06-26-coverage-group-uploads
Jun 26, 2026
Merged

ci(coverage): merge per-integration coverage in All Green before upload#9086
BridgeAR merged 5 commits into
masterfrom
BridgeAR/2026-06-26-coverage-group-uploads

Conversation

@BridgeAR

Copy link
Copy Markdown
Member

Summary

Each test cell uploads its own report to Codecov, so a commit sends ~430 uploads. Codecov silently parks uploads past its ~150-per-commit ceiling in started and never merges them — roughly 40 reports' worth of coverage was dropped from every commit (see #9073, where this surfaced as "40 started, 393 merged"). Separately, the Datadog coverage upload was broken: upload-coverage-artifact probed for files with find -maxdepth 1, but the LCOV lives one level deeper at coverage/node-<version>/lcov.info, so no coverage-* artifact was ever produced and datadog-ci coverage upload reported nothing while passing green.

All Green already downloads every coverage-* artifact to drive the Datadog upload, so it is the one place that sees a commit's whole coverage. It now folds the per-cell reports into one merged LCOV per integration and uploads the groups to both backends:

  1. upload-coverage-artifact recurses for lcov.info (fixing the Datadog starvation) and names each artifact coverage-<flag>__<job>-<index> so matrix cells that share a flag (cypress varies spec outside its flag) stop clobbering each other.
  2. scripts/merge-coverage-groups.mjs groups cells by integration — stripping Node.js and library versions, which are noise for "which integration regressed" — and merges each group's LCOV by summing hit counters. Producers already wrote each report through the patched getLineCoverage, so the text merge needs no istanbul dependency in All Green's sparse checkout. ~430 cells collapse to ~100 readable groups (apm-integrations-next, serverless-aws-sdk-s3).
  3. The per-cell Codecov upload is removed; All Green uploads one report per group to Codecov (CLI directly, to avoid re-validating the uploader ~100×) and Datadog, both flagged with the integration name.

Why

Fewer uploads is the only thing that actually fixes the Codecov ceiling, and the grouping is anchored on the workflow/flag rather than a hand-maintained map, so a new test job lands in its integration automatically. The merge runs with zero GitHub REST calls and no actions/cache use, so it adds no rate-limit pressure — and removing ~430 codecov-action invocations (each a tokenless validation Codecov runs against GitHub) reduces it.

master-coverage still rides every Codecov upload on PRs targeting master so the codecov/patch gate fires; reruns de-duplicate to the newest run so a stale rerun's counters are not double-counted.

Test plan

  • scripts/merge-coverage-groups.spec.mjs (run by test:scripts) covers integration stripping, lcov-merge summing, rerun de-dup, multi-version cells, and flag bucketing.
  • On a real run, confirm Codecov sessions land all MERGED (no started) and datadog-ci coverage upload reports a non-zero file count per group.
  • Confirm CODECOV_TOKEN secret is configured; without it the CLI falls back to tokenless upload (unchanged from today's behavior).

Each test cell uploaded its own report to Codecov, so a commit sent ~430
uploads. Codecov silently parks uploads past its ~150-per-commit ceiling in
`started` and never merges them, so roughly 40 reports' worth of coverage was
dropped from every commit. The Datadog coverage upload was a separate, broken
path: `upload-coverage-artifact` probed for files with `find -maxdepth 1`, but
the LCOV lives one level deeper at `coverage/node-<version>/lcov.info`, so the
check found nothing, no `coverage-*` artifact was ever produced, and
`datadog-ci coverage upload` reported nothing while passing green.

All Green already downloads every `coverage-*` artifact to drive the Datadog
upload, so it is the one place that sees the whole commit's coverage. It now
folds those per-cell reports into one merged LCOV per integration and uploads
the groups to both backends:

1. `upload-coverage-artifact` recurses for `lcov.info`, fixing the Datadog
   starvation, and names each artifact `coverage-<flag>__<job>-<index>` so
   matrix cells that share a flag (cypress varies `spec` outside its flag) stop
   clobbering each other under one name.
2. `merge-coverage-groups.mjs` groups cells by integration — stripping Node.js
   and library versions, which are noise for "which integration regressed" —
   and merges each group's LCOV by summing hit counters. The producers already
   wrote each report through the patched `getLineCoverage`, so the text merge
   needs no istanbul dependency in All Green's sparse checkout. ~430 cells
   collapse to ~100 readable groups (`apm-integrations-next`,
   `serverless-aws-sdk-s3`), well under the ceiling.
3. The per-cell Codecov upload is gone; All Green uploads one report per group
   to Codecov (CLI directly, to avoid re-validating the uploader ~100 times)
   and Datadog, both flagged with the integration name.

`master-coverage` still rides every Codecov upload on PRs targeting master so
the `codecov/patch` gate fires; reruns are de-duplicated to the newest run so a
stale rerun's counters are not double-counted.
@dd-octo-sts

dd-octo-sts Bot commented Jun 26, 2026

Copy link
Copy Markdown
Contributor

Overall package size

Self size: 6.36 MB
Deduped: 7.42 MB
No deduping: 7.42 MB

Dependency sizes | name | version | self size | total size | |------|---------|-----------|------------| | import-in-the-middle | 3.2.0 | 104.26 kB | 843.44 kB | | opentracing | 0.14.7 | 194.81 kB | 194.81 kB | | dc-polyfill | 0.1.11 | 25.74 kB | 25.74 kB |

🤖 This report was automatically generated by heaviest-objects-in-the-universe

@datadog-prod-us1-5

datadog-prod-us1-5 Bot commented Jun 26, 2026

Copy link
Copy Markdown

Tests

Fix all issues with BitsAI

⚠️ Warnings

1 Test performance regression detected

profiler on non-Windows platforms dns timeline events work from on non-Windows platforms — 4.9s (+3.97s, +428%)   View in Datadog

ℹ️ Info

No other issues found (see more)

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
Patch Coverage: 100.00%
Overall Coverage: 87.87%

Useful? React with 👍 / 👎

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 08fcc11 | Docs | Datadog PR Page | Give us feedback!

@pr-commenter

pr-commenter Bot commented Jun 26, 2026

Copy link
Copy Markdown

Benchmarks

Benchmark execution time: 2026-06-26 15:58:34

Comparing candidate commit 08fcc11 in PR branch BridgeAR/2026-06-26-coverage-group-uploads with baseline commit aab4813 in branch master.

📊 Benchmarking dashboard

Found 0 performance improvements and 0 performance regressions! Performance is the same for 2263 metrics, 20 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

  • 🟩 = significantly better candidate vs. baseline
  • 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

Unstable benchmarks

These benchmarks have a confidence interval too wide to call a change; treat them as noise rather than signal.

scenario:appsec-appsec-enabled-24

  • unstable execution_time [-150.392ms; +147.725ms] or [-5.776%; +5.674%]

scenario:appsec-appsec-enabled-26

  • unstable execution_time [-171.044ms; +175.764ms] or [-6.868%; +7.057%]

scenario:appsec-control-20

  • unstable execution_time [-121.575ms; +145.479ms] or [-7.123%; +8.523%]

scenario:appsec-control-24

  • unstable execution_time [-90931.554µs; +90094.187µs] or [-7.590%; +7.520%]

scenario:appsec-control-26

  • unstable execution_time [-94.764ms; +97.203ms] or [-7.995%; +8.201%]

scenario:dogstatsd-with-tags-20

  • unstable cpu_user_time [-386.969ms; +310.234ms] or [-7.806%; +6.258%]
  • unstable execution_time [-386.808ms; +310.168ms] or [-7.689%; +6.166%]
  • unstable throughput [-104509.233op/s; +130593.351op/s] or [-6.262%; +7.825%]

scenario:plugin-graphql-long-with-depth-and-collapse-off-24

  • unstable cpu_user_time [-361.687ms; +236.716ms] or [-8.164%; +5.343%]
  • unstable execution_time [-392.284ms; +256.166ms] or [-8.322%; +5.434%]
  • unstable max_rss_usage [-55.289MB; +33.550MB] or [-10.452%; +6.343%]
  • unstable throughput [-2.400op/s; +3.866op/s] or [-5.298%; +8.532%]

scenario:plugin-graphql-long-with-depth-off-20

  • unstable max_rss_usage [-9.624MB; +14.145MB] or [-6.662%; +9.791%]

scenario:plugin-graphql-long-with-depth-off-26

  • unstable max_rss_usage [-16.455MB; +24.678MB] or [-10.112%; +15.165%]

scenario:plugin-redis-churn-26

  • unstable cpu_user_time [-117.919ms; +72.271ms] or [-9.566%; +5.863%]
  • unstable execution_time [-115.181ms; +71.055ms] or [-9.162%; +5.652%]
  • unstable instructions [-1215.8M instructions; +741.3M instructions] or [-8.570%; +5.225%]
  • unstable throughput [-441086.678op/s; +707602.384op/s] or [-10.851%; +17.407%]

scenario:plugin-redis-mset-wide-24

  • unstable cpu_user_time [-264.079ms; +130.856ms] or [-7.035%; +3.486%]
  • unstable execution_time [-263.943ms; +130.394ms] or [-7.010%; +3.463%]

@codecov

codecov Bot commented Jun 26, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.55%. Comparing base (aab4813) to head (08fcc11).
⚠️ Report is 3 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #9086      +/-   ##
==========================================
+ Coverage   92.51%   93.55%   +1.04%     
==========================================
  Files         885      886       +1     
  Lines       50794    50733      -61     
  Branches    10018    11778    +1760     
==========================================
+ Hits        46990    47463     +473     
+ Misses       3804     3270     -534     
Flag Coverage Δ
aiguard 34.90% <ø> (?)
aiguard-integration 41.88% <ø> (?)
aiguard-integration-active ?
aiguard-integration-latest ?
aiguard-integration-maintenance ?
aiguard-macos ?
aiguard-ubuntu ?
aiguard-windows ?
apm-bucket-0 34.87% <ø> (?)
apm-bucket-1 40.40% <ø> (?)
apm-bucket-2 37.39% <ø> (?)
apm-capabilities-tracing 48.67% <ø> (?)
apm-capabilities-tracing-macos ?
apm-capabilities-tracing-ubuntu-latest ?
apm-capabilities-tracing-ubuntu-maintenance ?
apm-capabilities-tracing-ubuntu-oldest ?
apm-capabilities-tracing-windows ?
apm-integrations-aerospike 33.14% <ø> (?)
apm-integrations-aerospike-18-gte.5.2.0 ?
apm-integrations-aerospike-20-gte.5.5.0 ?
apm-integrations-aerospike-22-gte.5.12.1 ?
apm-integrations-aerospike-22-gte.6.0.0 ?
apm-integrations-aerospike-eol- ?
apm-integrations-child-process ?
apm-integrations-confluentinc-kafka-javascript 40.09% <ø> (?)
apm-integrations-confluentinc-kafka-javascript-20 ?
apm-integrations-confluentinc-kafka-javascript-22 ?
apm-integrations-confluentinc-kafka-javascript-24 ?
apm-integrations-couchbase 33.43% <ø> (?)
apm-integrations-couchbase-eol ?
apm-integrations-couchbase-oldest ?
apm-integrations-dns ?
apm-integrations-elasticsearch ?
apm-integrations-http 42.12% <ø> (?)
apm-integrations-http-latest ?
apm-integrations-http-maintenance ?
apm-integrations-http-oldest ?
apm-integrations-http2 ?
apm-integrations-kafkajs 40.33% <ø> (?)
apm-integrations-kafkajs-latest ?
apm-integrations-kafkajs-oldest ?
apm-integrations-next 29.50% <ø> (?)
apm-integrations-next-11.1.4 ?
apm-integrations-next-12.3.7 ?
apm-integrations-next-13.0.0 ?
apm-integrations-next-13.2.0 ?
apm-integrations-next-13.5.11 ?
apm-integrations-next-14.0.0 ?
apm-integrations-next-14.2.35 ?
apm-integrations-next-14.2.6 ?
apm-integrations-next-14.2.7 ?
apm-integrations-next-15.0.0 ?
apm-integrations-next-15.4.0 ?
apm-integrations-next-latest ?
apm-integrations-oracledb ?
apm-integrations-prisma 35.06% <ø> (?)
apm-integrations-prisma-18-gte.6.16.0.and.lt.7.0.0 ?
apm-integrations-prisma-latest-all ?
apm-integrations-restify ?
apm-integrations-sharedb ?
apm-integrations-tedious 33.92% <ø> (-0.04%) ⬇️
appsec 57.42% <ø> (?)
appsec-express_fastify_graphql 53.88% <ø> (?)
appsec-graphql ?
appsec-integration 36.20% <ø> (?)
appsec-integration-active ?
appsec-integration-latest ?
appsec-integration-maintenance ?
appsec-kafka_ldapjs_lodash 43.67% <ø> (?)
appsec-ldapjs ?
appsec-lodash ?
appsec-macos ?
appsec-mongodb-core ?
appsec-mongodb-core_mongoose_mysql 48.84% <ø> (?)
appsec-mysql ?
appsec-next 27.99% <ø> (?)
appsec-next-latest-11.1.4 ?
appsec-next-latest-12.3.7 ?
appsec-next-latest-13.0.0 ?
appsec-next-latest-13.2.0 ?
appsec-next-latest-13.5.11 ?
appsec-next-latest-14.0.0 ?
appsec-next-latest-14.2.35 ?
appsec-next-latest-14.2.6 ?
appsec-next-latest-14.2.7 ?
appsec-next-latest-15.0.0 ?
appsec-next-latest-latest ?
appsec-next-oldest-11.1.4 ?
appsec-next-oldest-12.3.7 ?
appsec-next-oldest-13.0.0 ?
appsec-next-oldest-13.2.0 ?
appsec-next-oldest-14.0.0 ?
appsec-next-oldest-14.2.35 ?
appsec-next-oldest-14.2.6 ?
appsec-next-oldest-14.2.7 ?
appsec-next-oldest-15.0.0 ?
appsec-next-oldest-latest ?
appsec-node-serialize ?
appsec-node-serialize_passport_postgres 48.08% <ø> (?)
appsec-passport ?
appsec-postgres ?
appsec-sourcing ?
appsec-sourcing_stripe_template 45.63% <ø> (?)
appsec-stripe ?
appsec-ubuntu ?
appsec-windows ?
debugger 43.83% <ø> (?)
debugger-ubuntu-active ?
debugger-ubuntu-latest ?
debugger-ubuntu-maintenance ?
debugger-ubuntu-oldest ?
instrumentations-bucket-0 28.14% <ø> (?)
instrumentations-bucket-1 37.45% <ø> (?)
instrumentations-bucket-10 40.49% <ø> (?)
instrumentations-bucket-11 27.94% <ø> (?)
instrumentations-bucket-12 28.66% <ø> (?)
instrumentations-bucket-13 27.77% <ø> (?)
instrumentations-bucket-2 30.23% <ø> (?)
instrumentations-bucket-3 35.94% <ø> (?)
instrumentations-bucket-4 28.05% <ø> (?)
instrumentations-bucket-5 36.31% <ø> (?)
instrumentations-bucket-6 38.31% <ø> (?)
instrumentations-bucket-7 35.95% <ø> (?)
instrumentations-bucket-8 37.00% <ø> (?)
instrumentations-bucket-9 39.58% <ø> (?)
instrumentations-instrumentation-ai ?
instrumentations-instrumentation-aws-sdk ?
instrumentations-instrumentation-bluebird ?
instrumentations-instrumentation-body-parser ?
instrumentations-instrumentation-child_process ?
instrumentations-instrumentation-connect ?
instrumentations-instrumentation-cookie-parser ?
instrumentations-instrumentation-couchbase 46.67% <ø> (?)
instrumentations-instrumentation-couchbase-18 ?
instrumentations-instrumentation-couchbase-eol ?
instrumentations-instrumentation-crypto ?
instrumentations-instrumentation-express ?
instrumentations-instrumentation-express-mongo-sanitize ?
instrumentations-instrumentation-express-multi-version ?
instrumentations-instrumentation-express-session ?
instrumentations-instrumentation-fastify ?
instrumentations-instrumentation-fetch ?
instrumentations-instrumentation-fs ?
instrumentations-instrumentation-generic-pool ?
instrumentations-instrumentation-hono ?
instrumentations-instrumentation-http ?
instrumentations-instrumentation-http-client-options ?
instrumentations-instrumentation-kafkajs ?
instrumentations-instrumentation-knex ?
instrumentations-instrumentation-koa ?
instrumentations-instrumentation-light-my-request ?
instrumentations-instrumentation-mongoose ?
instrumentations-instrumentation-multer ?
instrumentations-instrumentation-mysql2 ?
instrumentations-instrumentation-openai-lifecycle ?
instrumentations-instrumentation-otel-sdk-trace ?
instrumentations-instrumentation-passport ?
instrumentations-instrumentation-passport-http ?
instrumentations-instrumentation-passport-local ?
instrumentations-instrumentation-pg ?
instrumentations-instrumentation-promise ?
instrumentations-instrumentation-promise-js ?
instrumentations-instrumentation-q ?
instrumentations-instrumentation-restify ?
instrumentations-instrumentation-router ?
instrumentations-instrumentation-stripe ?
instrumentations-instrumentation-url ?
instrumentations-instrumentation-when ?
instrumentations-instrumentation-zlib ?
instrumentations-integration-esbuild 24.75% <ø> (?)
instrumentations-integration-esbuild-0.16.12-latest ?
instrumentations-integration-esbuild-0.16.12-maintenance ?
instrumentations-integration-esbuild-0.16.12-oldest ?
instrumentations-integration-esbuild-latest-active ?
instrumentations-integration-esbuild-latest-latest ?
instrumentations-integration-esbuild-latest-maintenance ?
instrumentations-integration-esbuild-latest-oldest ?
llmobs-ai ?
llmobs-ai_anthropic_bedrock 39.48% <ø> (?)
llmobs-anthropic ?
llmobs-bedrock ?
llmobs-google-genai ?
llmobs-google-genai_langchain_vertex-ai 36.80% <ø> (?)
llmobs-langchain ?
llmobs-openai 39.55% <ø> (?)
llmobs-openai-latest ?
llmobs-openai-oldest ?
llmobs-sdk 43.52% <ø> (?)
llmobs-sdk-active ?
llmobs-sdk-latest ?
llmobs-sdk-maintenance ?
llmobs-sdk-oldest ?
llmobs-vertex-ai ?
master-coverage 93.55% <ø> (?)
openfeature 37.84% <ø> (?)
openfeature-macos ?
openfeature-ubuntu ?
openfeature-unit 50.62% <ø> (?)
openfeature-unit-active ?
openfeature-unit-latest ?
openfeature-unit-maintenance ?
openfeature-unit-oldest ?
openfeature-windows ?
platform-core ?
platform-core_esbuild_instrumentations-misc 23.21% <ø> (?)
platform-esbuild ?
platform-instrumentations-misc ?
platform-integration 47.54% <ø> (?)
platform-integration-active ?
platform-integration-maintenance ?
platform-integration-oldest ?
platform-shimmer ?
platform-shimmer_unit-guardrails_webpack 18.86% <ø> (?)
platform-unit-guardrails ?
platform-webpack ?
plugins-axios ?
plugins-azure-cosmos ?
plugins-azure-event-hubs ?
plugins-azure-service-bus ?
plugins-body-parser ?
plugins-bucket-0 36.36% <ø> (?)
plugins-bucket-1 39.66% <ø> (?)
plugins-bucket-11 38.51% <ø> (?)
plugins-bucket-17 39.21% <ø> (?)
plugins-bucket-18 42.15% <ø> (?)
plugins-bucket-19 39.61% <ø> (?)
plugins-bucket-20 43.13% <ø> (?)
plugins-bucket-4 37.76% <ø> (?)
plugins-bullmq_cassandra_cookie 39.82% <ø> (?)
plugins-cassandra ?
plugins-cookie ?
plugins-cookie-parser ?
plugins-cookie-parser_crypto_dd-trace-api 33.24% <ø> (?)
plugins-crypto ?
plugins-dd-trace-api ?
plugins-express-mongo-sanitize ?
plugins-express-session ?
plugins-fastify ?
plugins-fetch ?
plugins-fetch_fs_generic-pool 36.09% <ø> (?)
plugins-fs ?
plugins-generic-pool ?
plugins-google-cloud-pubsub ?
plugins-google-cloud-pubsub_grpc_handlebars 43.18% <ø> (?)
plugins-grpc ?
plugins-handlebars ?
plugins-hapi ?
plugins-hapi_hono_ioredis 37.83% <ø> (?)
plugins-hono ?
plugins-ioredis ?
plugins-jest ?
plugins-jest_knex_langgraph 32.62% <ø> (?)
plugins-knex ?
plugins-langgraph ?
plugins-ldapjs ?
plugins-ldapjs_light-my-request_limitd-client 27.83% <ø> (?)
plugins-light-my-request ?
plugins-limitd-client ?
plugins-lodash ?
plugins-lodash_mariadb_memcached 35.21% <ø> (?)
plugins-mariadb ?
plugins-memcached ?
plugins-modelcontextprotocol-sdk ?
plugins-moleculer ?
plugins-mongodb ?
plugins-mongodb-core ?
plugins-mongodb_mongodb-core_mongoose 36.35% <ø> (?)
plugins-mongoose ?
plugins-multer ?
plugins-multer_mysql_mysql2 35.13% <ø> (?)
plugins-mysql ?
plugins-mysql2 ?
plugins-nats ?
plugins-nats_node-serialize_opensearch 37.14% <ø> (?)
plugins-node-serialize ?
plugins-opensearch ?
plugins-passport-http ?
plugins-passport-http_pino_postgres 35.57% <ø> (?)
plugins-pino ?
plugins-postgres ?
plugins-process ?
plugins-process_pug_redis 34.29% <ø> (?)
plugins-pug ?
plugins-redis ?
plugins-router ?
plugins-sequelize ?
plugins-test-and-upstream-amqp10 ?
plugins-test-and-upstream-amqplib ?
plugins-test-and-upstream-apollo ?
plugins-test-and-upstream-avsc ?
plugins-test-and-upstream-bunyan ?
plugins-test-and-upstream-connect ?
plugins-test-and-upstream-graphql ?
plugins-test-and-upstream-koa ?
plugins-test-and-upstream-protobufjs ?
plugins-test-and-upstream-rhea ?
plugins-undici ?
plugins-undici_url_valkey 35.91% <ø> (?)
plugins-url ?
plugins-valkey ?
plugins-vm ?
plugins-vm_winston_ws 37.60% <ø> (?)
plugins-winston ?
plugins-ws ?
profiling 43.75% <ø> (?)
profiling-macos ?
profiling-ubuntu ?
profiling-windows ?
serverless-aws-sdk-aws-sdk 33.30% <ø> (?)
serverless-aws-sdk-bedrockruntime 32.15% <ø> (?)
serverless-aws-sdk-client 37.27% <ø> (?)
serverless-aws-sdk-dynamodb 34.10% <ø> (?)
serverless-aws-sdk-eventbridge 27.23% <ø> (?)
serverless-aws-sdk-kinesis 37.41% <ø> (?)
serverless-aws-sdk-lambda 34.58% <ø> (?)
serverless-aws-sdk-latest-aws-sdk ?
serverless-aws-sdk-latest-bedrockruntime ?
serverless-aws-sdk-latest-client ?
serverless-aws-sdk-latest-dynamodb ?
serverless-aws-sdk-latest-eventbridge ?
serverless-aws-sdk-latest-kinesis ?
serverless-aws-sdk-latest-s3 ?
serverless-aws-sdk-latest-serverless-peer-service ?
serverless-aws-sdk-latest-sqs ?
serverless-aws-sdk-latest-stepfunctions ?
serverless-aws-sdk-latest-util ?
serverless-aws-sdk-oldest-aws-sdk ?
serverless-aws-sdk-oldest-bedrockruntime ?
serverless-aws-sdk-oldest-client ?
serverless-aws-sdk-oldest-dynamodb ?
serverless-aws-sdk-oldest-eventbridge ?
serverless-aws-sdk-oldest-kinesis ?
serverless-aws-sdk-oldest-s3 ?
serverless-aws-sdk-oldest-serverless-peer-service ?
serverless-aws-sdk-oldest-sns ?
serverless-aws-sdk-oldest-sqs ?
serverless-aws-sdk-oldest-stepfunctions ?
serverless-aws-sdk-s3 32.57% <ø> (?)
serverless-aws-sdk-serverless-peer-service 39.50% <ø> (?)
serverless-aws-sdk-sns 38.27% <ø> (?)
serverless-aws-sdk-sqs 38.01% <ø> (?)
serverless-aws-sdk-stepfunctions 33.18% <ø> (?)
serverless-aws-sdk-util 48.15% <ø> (?)
serverless-azure-durable-functions ?
serverless-azure-functions-eventhubs ?
serverless-azure-functions-servicebus ?
serverless-bucket-0 39.52% <ø> (?)
serverless-lambda 34.36% <ø> (-0.05%) ⬇️
test-optimization-cucumber 52.67% <ø> (?)
test-optimization-cucumber-latest-7.0.0 ?
test-optimization-cucumber-latest-latest ?
test-optimization-cucumber-oldest-7.0.0 ?
test-optimization-cypress 49.76% <ø> (?)
test-optimization-cypress-latest-12.0.0-commonJS ?
test-optimization-cypress-latest-12.0.0-esm ?
test-optimization-cypress-latest-14.5.4-commonJS ?
test-optimization-cypress-latest-14.5.4-esm ?
test-optimization-cypress-latest-latest-commonJS ?
test-optimization-cypress-latest-latest-esm ?
test-optimization-cypress-oldest-12.0.0-commonJS ?
test-optimization-cypress-oldest-12.0.0-esm ?
test-optimization-cypress-oldest-14.5.4-commonJS ?
test-optimization-cypress-oldest-14.5.4-esm ?
test-optimization-jest 55.79% <ø> (?)
test-optimization-jest-latest-latest ?
test-optimization-jest-latest-oldest ?
test-optimization-jest-oldest-latest ?
test-optimization-jest-oldest-oldest ?
test-optimization-mocha 53.81% <ø> (?)
test-optimization-mocha-latest-latest ?
test-optimization-mocha-latest-oldest ?
test-optimization-mocha-oldest-latest ?
test-optimization-mocha-oldest-oldest ?
test-optimization-playwright-latest-latest-playwright-active-test-span ?
test-optimization-playwright-latest-latest-playwright-atr ?
test-optimization-playwright-latest-latest-playwright-efd ?
test-optimization-playwright-latest-latest-playwright-final-status ?
test-optimization-playwright-latest-latest-playwright-impacted-tests ?
test-optimization-playwright-latest-latest-playwright-reporting ?
test-optimization-playwright-latest-latest-playwright-test-management ?
test-optimization-playwright-latest-oldest-playwright-active-test-span ?
test-optimization-playwright-latest-oldest-playwright-atr ?
test-optimization-playwright-latest-oldest-playwright-efd ?
test-optimization-playwright-latest-oldest-playwright-final-status ?
test-optimization-playwright-latest-oldest-playwright-impacted-tests ?
test-optimization-playwright-latest-oldest-playwright-reporting ?
test-optimization-playwright-latest-oldest-playwright-test-management ?
test-optimization-playwright-oldest-latest-playwright-active-test-span ?
test-optimization-playwright-oldest-latest-playwright-atr ?
test-optimization-playwright-oldest-latest-playwright-efd ?
test-optimization-playwright-oldest-latest-playwright-final-status ?
test-optimization-playwright-oldest-latest-playwright-impacted-tests ?
test-optimization-playwright-oldest-latest-playwright-reporting ?
test-optimization-playwright-oldest-latest-playwright-test-management ?
test-optimization-playwright-oldest-oldest-playwright-active-test-span ?
test-optimization-playwright-oldest-oldest-playwright-efd ?
test-optimization-playwright-oldest-oldest-playwright-impacted-tests ?
test-optimization-playwright-oldest-oldest-playwright-reporting ?
test-optimization-playwright-oldest-oldest-playwright-test-management ?
test-optimization-playwright-playwright-atr 43.70% <ø> (?)
test-optimization-playwright-playwright-efd 43.99% <ø> (?)
test-optimization-playwright-playwright-final-status 44.28% <ø> (?)
test-optimization-playwright-playwright-impacted-tests 43.53% <ø> (?)
test-optimization-playwright-playwright-reporting 43.61% <ø> (?)
test-optimization-playwright-playwright-test-management 45.06% <ø> (?)
test-optimization-playwright-playwright-test-span 44.90% <ø> (?)
test-optimization-selenium 45.63% <ø> (?)
test-optimization-selenium-latest ?
test-optimization-selenium-oldest ?
test-optimization-testopt 48.37% <ø> (?)
test-optimization-testopt-active ?
test-optimization-testopt-latest ?
test-optimization-testopt-maintenance ?
test-optimization-testopt-oldest ?
test-optimization-vitest 51.08% <ø> (?)
test-optimization-vitest-latest ?
test-optimization-vitest-oldest ?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

BridgeAR added 2 commits June 26, 2026 14:55
The first cut merged each group's LCOV locally, reimplementing istanbul's
coverage-map merge as ~350 lines of LCOV text parsing. Both Codecov and Datadog
already merge same-flag uploads server-side — that is how they combined the ~430
per-cell reports before this change — so the local merge bought nothing and
carried the drift risk of a hand-rolled parser that has to round-trip every
field the backends read.

Drop it: All Green now sorts each cell's already-patched `lcov.info` into its
integration's directory and uploads the directory under one flag. Reports pass
through byte-for-byte, so the `getLineCoverage` patch the producers baked in
survives without needing a patched istanbul in All Green's sparse checkout, and
a future LCOV field needs no parser change.

Also drop the unused `CODECOV_TOKEN` env — the repo uploads tokenless and a
token would have to be an org secret that fork PRs cannot read.
…ives

Routing only lcov to Codecov collapsed branch coverage from ~10000 to ~30 and
method coverage from ~6250 to ~3: Codecov's lcov parser ingests line hits but
not istanbul's BRDA/FN records, so every file reported branches=0 (proxy.js:
44 branches on master, 0 here) while lines and overall coverage looked right.
The old per-cell upload avoided this by letting codecov-action search the
coverage directory, which picked up istanbul's coverage-final.json — its
NodeProcessor reads the full branch and function maps.

Restore that: every cell now also emits coverage-final.json (the unit nyc
config gained the json reporter; the integration harness already wrote one),
group-coverage sorts each cell's reports into coverage-upload/<group>/lcov and
.../json, and All Green uploads the JSON to Codecov and the lcov to Datadog —
Datadog does not ingest istanbul JSON. Codecov's directory search matches the
JSON because the copied name keeps the `coverage-` prefix.
@BridgeAR
BridgeAR marked this pull request as ready for review June 26, 2026 14:40
@BridgeAR
BridgeAR requested review from a team as code owners June 26, 2026 14:40

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c98789b6b9

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment thread scripts/group-coverage.mjs Outdated

@datadog-prod-us1-5 datadog-prod-us1-5 Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Datadog Autotest: WARN

The rerun deduplication in planCoverageGroups used JavaScript string comparison (runId > previous) instead of numeric comparison. When two workflow run IDs straddle a digit-length boundary — '9' vs '10' — the lexicographic order inverts, causing the older run's stale coverage to survive. Fixed to Number(runId) > Number(previous) with a regression test.

View proposed fix
📊 Validated against 10 scenarios · Open Bits AI session

🤖 Datadog Autotest · Commit c98789b · What is Autotest? · Any feedback? Reach out in #autotest

Comment thread scripts/group-coverage.mjs Outdated
BridgeAR added 2 commits June 26, 2026 17:04
…cally

Both backends reject any flag that fails Codecov's `^[\w\.\-]{1,45}$`, so the
two grouping bugs below silently dropped coverage for busy areas instead of
erroring.

1. Bucket flags joined member libraries with `+`, an invalid flag character;
   they now join with `_`, and a name that would overrun 45 characters falls
   back to a numbered bucket that stays valid.
2. The newest-run selection compared run ids as strings, so a rerun crossing a
   power-of-ten boundary (`'9' > '10'`) kept the older, stale failed run. The
   compare is now numeric.
Both upload steps walked the ~100 integration groups in a serial for loop, so
the runner sat idle waiting on one latency-bound request at a time while the
rest of the job was done. Each group uploads independently, so a 10-wide
xargs fan-out hides that latency. The Codecov create-commit/create-report
setup stays serial ahead of the fan-out, since only the do-upload calls are
independent.

@bengl bengl left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fine. We used to do this, but stopped for some reason I can't remember. @rochdev probably remembers.

@bengl bengl left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is fine. We used to do this, but stopped for some reason I can't remember. @rochdev probably remembers.

@BridgeAR
BridgeAR merged commit 42b241d into master Jun 26, 2026
805 checks passed
@BridgeAR
BridgeAR deleted the BridgeAR/2026-06-26-coverage-group-uploads branch June 26, 2026 20:59
This was referenced Jun 26, 2026
rochdev pushed a commit that referenced this pull request Jul 2, 2026
…ad (#9086)

Each test cell uploaded its own report to Codecov, so a commit sent ~430
uploads. Codecov silently parks uploads past its ~150-per-commit ceiling in
`started` and never merges them, so roughly 40 reports' worth of coverage was
dropped from every commit. The Datadog coverage upload was separately broken:
`upload-coverage-artifact` probed for files with `find -maxdepth 1`, but the
report lives one level deeper at `coverage/node-<version>/`, so the check found
nothing, no `coverage-*` artifact was produced, and `datadog-ci coverage
upload` reported nothing while passing green.

All Green already downloads every `coverage-*` artifact to drive the Datadog
upload, so it is the one place that sees a whole commit's coverage. It now
groups the per-cell reports by integration and uploads ~100 groups to both
backends instead of ~430 per-cell reports:

1. `upload-coverage-artifact` recurses for the report files and names each
   artifact `coverage-<flag>__<job>-<index>` so matrix cells that share a flag
   (cypress varies `spec` outside its flag) stop clobbering each other.
2. `scripts/group-coverage.mjs` sorts each cell's report into its integration's
   directory, stripping Node.js and library versions, which are noise for
   "which integration regressed". Reports are not merged locally — both
   backends merge same-flag uploads server-side — so each report passes through
   byte-for-byte and the harness needs no istanbul dependency in All Green's
   sparse checkout. ~430 cells collapse to ~100 groups.
3. Each cell emits both lcov and istanbul JSON: Codecov reads branch and
   function coverage from the JSON (its lcov parser ingests only line hits),
   Datadog reads the lcov and does not ingest the JSON. All Green uploads each
   format to the backend that reads it, one group per integration, flagged with
   the integration name.

`master-coverage` still rides every Codecov upload on PRs targeting master so
the `codecov/patch` gate fires; reruns de-duplicate to the newest run so a
stale rerun's counters are not double-counted.
rochdev pushed a commit that referenced this pull request Jul 2, 2026
…ad (#9086)

Each test cell uploaded its own report to Codecov, so a commit sent ~430
uploads. Codecov silently parks uploads past its ~150-per-commit ceiling in
`started` and never merges them, so roughly 40 reports' worth of coverage was
dropped from every commit. The Datadog coverage upload was separately broken:
`upload-coverage-artifact` probed for files with `find -maxdepth 1`, but the
report lives one level deeper at `coverage/node-<version>/`, so the check found
nothing, no `coverage-*` artifact was produced, and `datadog-ci coverage
upload` reported nothing while passing green.

All Green already downloads every `coverage-*` artifact to drive the Datadog
upload, so it is the one place that sees a whole commit's coverage. It now
groups the per-cell reports by integration and uploads ~100 groups to both
backends instead of ~430 per-cell reports:

1. `upload-coverage-artifact` recurses for the report files and names each
   artifact `coverage-<flag>__<job>-<index>` so matrix cells that share a flag
   (cypress varies `spec` outside its flag) stop clobbering each other.
2. `scripts/group-coverage.mjs` sorts each cell's report into its integration's
   directory, stripping Node.js and library versions, which are noise for
   "which integration regressed". Reports are not merged locally — both
   backends merge same-flag uploads server-side — so each report passes through
   byte-for-byte and the harness needs no istanbul dependency in All Green's
   sparse checkout. ~430 cells collapse to ~100 groups.
3. Each cell emits both lcov and istanbul JSON: Codecov reads branch and
   function coverage from the JSON (its lcov parser ingests only line hits),
   Datadog reads the lcov and does not ingest the JSON. All Green uploads each
   format to the backend that reads it, one group per integration, flagged with
   the integration name.

`master-coverage` still rides every Codecov upload on PRs targeting master so
the `codecov/patch` gate fires; reruns de-duplicate to the newest run so a
stale rerun's counters are not double-counted.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants