Es/taskify reexecution

[Elvis339]

Why this should be merged

The polyrepo migration requires benchmark workflows to run in any repository (Firewood, Coreth, etc.) without depending on AvalancheGo infrastructure.

Current workflows use custom actions that reference themselves:

- uses: ./.github/actions/run-monitored-tmpnet-cmd

This breaks in other repos because they don't have AvalancheGo's custom actions directory. Copying actions to each repo creates duplication and maintenance burden.

This PR inlines all custom action logic directly into the workflow:

• Monitoring configuration moved into workflow steps
• Task configuration defined in JSON matrix
• Three duplicate workflows consolidated into one

The result is a self-contained trivially locally reproducable workflow with zero custom action dependencies. It can be invoked to any repository and work immediately. Execution simplifies to: ./scripts/run_task.sh <task-name> with config from JSON.

How this works

The workflow reads task configurations from c-chain-reexecution-benchmark-config.json based on the trigger event (pull_request, schedule, workflow_dispatch). It splits configurations into separate matrices for native GitHub runners and self-hosted ARC container runners to avoid compatibility issues.

On pull requests, it runs fast benchmarks (101-250k blocks) for validation. On schedule, it runs long benchmarks (33m-33m500k blocks) on performance-optimized runners. Manual dispatch accepts inputs to override the config for ad-hoc testing.

To reproduce locally just execute a task defined in Taskfile.

How this was tested

CI

Need to be documented in RELEASES.md?

No - internal CI/CD infrastructure.

[Copilot]

Pull Request Overview

This PR consolidates three separate C-Chain re-execution benchmark workflows into a single, self-contained workflow to support polyrepo migration. The changes eliminate custom GitHub Actions dependencies by inlining all logic directly into the workflow, making it portable across repositories without requiring custom action infrastructure.

Key Changes:

• Consolidated three workflows (native, container, and benchmark-specific) into one unified workflow
• Created five new Taskfile tasks for standardized benchmark execution
• Replaced custom GitHub Actions with inline workflow steps

Reviewed Changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
.github/workflows/c-chain-reexecution-benchmark.yml	New unified workflow supporting both native and self-hosted runners with task-based configuration
.github/workflows/c-chain-reexecution-benchmark-config.json	Configuration file defining benchmark tasks, runners, and timeouts for different trigger events
Taskfile.yml	Added five benchmark task definitions and AWS region configuration for directory export
.github/workflows/c-chain-reexecution-benchmark-gh-native.yml	Removed in favor of unified workflow
.github/workflows/c-chain-reexecution-benchmark-gh-native.json	Removed in favor of unified configuration
.github/workflows/c-chain-reexecution-benchmark-container.yml	Removed in favor of unified workflow
.github/workflows/c-chain-reexecution-benchmark-container.json	Removed in favor of unified configuration
.github/actions/c-chain-reexecution-benchmark/action.yml	Removed custom action, logic inlined into workflow

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[maru-ava]

While a transition from the previous json-defined workflows might be desirable, is it required to enable running reexecute tests as part of firewood CI?

If not, maybe focus this PR only on ensuring tasks for each reexecute configuration and a reexecute custom action that is reusable across repos?

[Elvis339]

While a transition from the previous json-defined workflows might be desirable, is it required to enable running reexecute tests as part of firewood CI?

If not, maybe focus this PR only on ensuring tasks for each reexecute configuration and a reexecute custom action that is reusable across repos?

It's not required, but I think it composes together nicely and serves as verification that everything works. Here's my reasoning:
For firewood CI, we need:

• Taskfile tasks for each config (done)
• Reusable custom action (main deliverable)

The workflow refactoring adds:

• Immediate verification the custom action works
• Eliminates ~250 lines of duplication

[maru-ava]

• Taskfile tasks for each config (done)
• Reusable custom action (main deliverable)

The workflow refactoring adds:

• Immediate verification the custom action works
• Eliminates ~250 lines of duplication

I was not arguing against the potential benefit, but I'm still not convinced that this PR is the appropriate place to be making such invasive changes. The shift to a reusable action should have negligible impact on the workflows, and the shift to using tasks is also unlikely to require complicated changes to the workflows. Limiting the focus of this PR to those changes would make for a much easier PR.

Taking the initiative to reduce duplication is laudable, but I don't think such changes should have to come at the cost of making separable changes harder to review.

[maru-ava]

Maybe enforce that this file must be an exact copy of the run-monitored-tmpnet-cmd version to minimize the potential for unintended drift?

[Elvis339]

I added sym link.

[maru-ava]

A symlink won't work when the action is used from other repos.

Edit: You'll need to confirm that a symlink will work when the action is used by other repos.

[maru-ava]

Maybe use {{.TASK}} as the value of TASK_NAME for this and all other modified tasks?

[Elvis339]

What's the requirement? Adding {{ .TASK }} as TASK_NAME results in parent name vs name of the executed task.

reexecute-cchain-range-with-copied-data-20251029-130410

[maru-ava]

(No action required) Given that the protocol, bucket and /** file glob are all common, maybe only require that the object path (i.e. cchain-mainnet-blocks-1m-ldb) be specified in this and the other tasks?

[Elvis339]

I think it should be part of the script and the script is made to be a bit more flexible.

0635d05

[Elvis339]

• Taskfile tasks for each config (done)
• Reusable custom action (main deliverable)

The workflow refactoring adds:

• Immediate verification the custom action works
• Eliminates ~250 lines of duplication

I was not arguing against the potential benefit, but I'm still not convinced that this PR is the appropriate place to be making such invasive changes. The shift to a reusable action should have negligible impact on the workflows, and the shift to using tasks is also unlikely to require complicated changes to the workflows. Limiting the focus of this PR to those changes would make for a much easier PR.

Taking the initiative to reduce duplication is laudable, but I don't think such changes should have to come at the cost of making separable changes harder to review.

You're right, and I apologize for overloading this PR. I should have been more thoughtful about separating concerns.
My thinking was that since we're already touching all these workflow files to switch to the reusable action, it made sense to include the task refactoring in the same pass especially because the CI provides immediate verification that everything works end-to-end. Testing a reusable action in isolation is tricky, and having real workflows exercise it felt like the safest way to validate the changes.

Would it help if I split this into two PRs one for the task definitions + their immediate usage, and another for the reusable action refactor?

I want to make this easier to review while still getting the validation benefits of CI. What would work best for you?

[maru-ava]

You're right, and I apologize for overloading this PR. I should have been more thoughtful about separating concerns. My thinking was that since we're already touching all these workflow files to switch to the reusable action, it made sense to include the task refactoring in the same pass especially because the CI provides immediate verification that everything works end-to-end. Testing a reusable action in isolation is tricky, and having real workflows exercise it felt like the safest way to validate the changes.

Would it help if I split this into two PRs one for the task definitions + their immediate usage, and another for the reusable action refactor?

I want to make this easier to review while still getting the validation benefits of CI. What would work best for you?

I would like to see this PR focus only on necessary changes - a custom action that doesn't rely on relative imports, workflows that externalize reexecute configuration to tasks. Anything more than that can be deferred to one or more subsequent PRs.