enhance(ci): add fast benchmark artifact workflow

[spencer-tb]

🗒️ Description

A follow up request from the benchmarking meeting in Devconnect Argentina. Adds new CI workflow artifact_benchmark_fast.yaml that builds benchmark fixtures with 100M gas on push to forks/osaka and forks/amsterdam branches, only for changes relevant to benchmark tests.

Renames release workflows with release_ prefix for better organization (fixture_full_release.yaml -> release_fixture_full.yaml, etc.)

To download the artifact we should be able to run the following below, to get the latest artifact:

gh run download -R ethereum/execution-specs -n fixtures_benchmark_fast

🔗 Related Issues or PRs

N/A.

✅ Checklist

• All: Ran fast tox checks to avoid unnecessary CI fails, see also Code Standards and Enabling Pre-commit Checks:

  uvx tox -e static

• All: PR title adheres to the repo standard - it will be used as the squash commit message and should start type(scope):.
• All: Considered adding an entry to CHANGELOG.md.
• All: Considered updating the online docs in the ./docs/ directory.
• All: Set appropriate labels for the changes (only maintainers can apply labels).

Cute Animal Picture

[LouisTsai-Csie]

Nice! Hope we could present this during gas lighting call!

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.31%. Comparing base (519eb26) to head (051d0f3).
⚠️ Report is 7 commits behind head on forks/osaka.

Additional details and impacted files

@@               Coverage Diff                @@
##           forks/osaka    #1827       +/-   ##
================================================
+ Coverage        53.45%   87.31%   +33.86%     
================================================
  Files              743      541      -202     
  Lines            44076    32832    -11244     
  Branches          3891     3015      -876     
================================================
+ Hits             23559    28668     +5109     
+ Misses           20306     3557    -16749     
- Partials           211      607      +396     

Flag	Coverage Δ
unittests	87.31% <ø> (+33.86%)	⬆️

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

☔ View full report in Codecov by Sentry.
📢 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.

[danceratopz]

Thanks for adding this, couple of comments below!

I do think this PR should be considered blocked by:

• #1804

I'm slightly concerned that relying on latest artifacts (as-is) will make it difficult to trace issues in downstream infra. One idea to mitigate this would be to enable artifact downloading in consume cache (which should then be used by Kamil, etc.) and enable logging of the execution-specs git ref (resp. URL) corresponding to the artifact being downloaded. Currently, this ref is already reported in the fixture JSON and in fixtures/.meta/fixtures.ini but something even more obvious wouldn't hurt.

E.g.:

• Q "I couldn't run the latest arfifact, is it broken?"
• A "What's the execution-specs ref in the download log for me to verify locally?

[danceratopz]

I think we should only generate for the default fork, especially as we only generate benchmark fixtures for Prague. I guess this will be Amsterdam very soon :)

[spencer-tb]

Agree here. There is not an automatic option for default fork here so leaving as is for now.

[danceratopz]

This could trigger a lot of unnecessary builds, but happy to leave as-is for now and see how it goes.

[spencer-tb]

Updated. Removed some of these.

[spencer-tb]

I'm slightly concerned that relying on latest artifacts (as-is) will make it difficult to trace issues in downstream infra. One idea to mitigate this would be to enable artifact downloading in consume cache (which should then be used by Kamil, etc.) and enable logging of the execution-specs git ref (resp. URL) corresponding to the artifact being downloaded. Currently, this ref is already reported in the fixture JSON and in fixtures/.meta/fixtures.ini but something even more obvious wouldn't hurt.

As far as I understand the git ref is traceable via:

gh run list -R ethereum/execution-specs -w "Build Benchmark Fixtures" --limit 5

Then can be downloaded from a specific run if needed:

gh run download -R ethereum/execution-specs <run-id> -n fixtures_benchmark_fast

I agree adding more obvious logging in consume cache would be a nice improvement, but I'd
prefer to address that in a follow-up PR!

[marioevz]

Amazing, thanks!