Add network_uuid filter to Grafana URLs for matrix job differentiation

[Copilot]

Why this should be merged

Matrix jobs sharing the same workflow and job ID produce Grafana URLs that aggregate metrics across all jobs, conflating results from distinct block ranges. Each job already exports a unique network_uuid label, but it wasn't included in the Grafana URL filters.

How this works

UUID lifecycle:

• Generate once per job: c-chain-reexecution-benchmark action creates UUID via uuidgen
• Pass through environment: UUID flows via NETWORK_UUID env var to all steps
• Reuse in Go test: getOrCreateNetworkUUID() reads env var instead of generating new UUID
• Filter Grafana URL: output-metrics-url.sh appends &var-filter=network_uuid|=|{UUID} when set

Key changes:

• vm_reexecute_test.go: Added getOrCreateNetworkUUID() helper, moved UUID init to TestMain
• output-metrics-url.sh: Conditional network_uuid filter in URL construction
• run-monitored-tmpnet-cmd/action.yml: New network_uuid input parameter
• c-chain-reexecution-benchmark/action.yml: Generate and propagate UUID

Result: Each matrix job gets isolated metrics in Grafana, no more cross-job aggregation.

How this was tested

• Go build and vet pass
• Shellcheck passes
• Unit tested UUID fallback logic and URL construction

Need to be documented in RELEASES.md?

No. Internal CI/metrics infrastructure change.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Ensure Matrix of Re-Execution Jobs within a Single Workflow get a unique label set</issue_title>
<issue_description>Currently, a matrix of re-execution tests created from the same workflow link a Grafana URL that includes a set of pre-supplied labels and attempts to show the metrics from that specific job.

However, since multiple jobs in the same matrix share an identical jobID they end up with the same workflow and jobID and the linked Grafana URL shows metrics across multiple re-execution runs, which may produce an inaccurate view of what the user is trying to see. For example, if a workflow triggers jobs multiple distinct ranges of blocks, users should see metrics from those two distinct ranges and not conflate mgas/s across two different ranges. Since the C-Chain dashboard frequently uses aggregates, this results in a particularly inaccurate view.

Each individual job does receive a unique network_uuid and this is already included as a label on the exported metrics, so adding the network_uuid to the set of labels included in the Grafana URL should be sufficient to differentiate them.</issue_description>

<agent_instructions>Create the networkUUID by creating an environment variable and adding it to the environment from the c-chain-reexecution-benchmark action.

In output-metrics-url.sh if that env var is set, include a filter for it as network_uuid=value. Then in vm_reexecute_test.sh add a non-exported function called getOrCreateNetworkUUID that checks for the env var first and creates a new UUID in the same way it does now if it does not find one.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@aaronbuchwald Hmm it seems that the network UUID is currently created by the golang code _after_ the grafana URL has been printed out: https://github.com/ava-labs/avalanchego/blob/29b4e6bc541bcd913da6c51c1c5403fff2e377a4/tests/reexecute/c/vm_reexecute_test.go#L70 so need to pass this info around slightly differently.

• Fixes Ensure Matrix of Re-Execution Jobs within a Single Workflow get a unique label set #4502

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.