enhance(spec-tool): create blob parameter-only hardforks on the fly - #1789
Conversation
c0ddae7 to
bfbe9d6
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## forks/osaka #1789 +/- ##
===============================================
- Coverage 87.31% 83.87% -3.45%
===============================================
Files 541 402 -139
Lines 32832 25101 -7731
Branches 3015 2285 -730
===============================================
- Hits 28668 21053 -7615
- Misses 3557 3609 +52
+ Partials 607 439 -168
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
spencer-tb
left a comment
There was a problem hiding this comment.
LGTM!
FYI I am filling with:
uv run fill --from=Osaka --until=BPO4 --clean -n 4 -k BPO -v
|
@spencer-tb should I add |
Yes please! Totally forgot 😓 |
|
Done :3 |
|
cc-ing from Discord: I think this is the cause for the CI fails. The AI tells me to add this here. exit_code = libcst_tool(
"<libcst_tool>",
[args[0], "-j", "1"] + args[1:],
) |
marioevz
left a comment
There was a problem hiding this comment.
Thanks, just one comment that I think should skip having to generate temporary forks if the BPO values are unchanged.
| if all(x is None for x in cache_key[1:]): | ||
| return template |
There was a problem hiding this comment.
We currently pass the blob parameters unconditionally from the tests, i.e. as long as the fork supports blobs we pass the parameters. And I think we are generating an unnecessary exact copy of the fork in that case.
We could skip this for forks that are defined in the transition tool and only pass the blob parameters if the BPO fork is undefined.
I.e. for Osaka, BPO1 and BPO2, which are defined src/ethereum/forks (BPO1 and BPO2 not yet but eventually), we pass directly the name and skip the BPO parameters. But for example, if we want to test BPO3, which is still undefined in the specs, then in that case we do pass the parameters along with the Osaka fork name.
We have to guarantee that the BPO parameter values match in the specs and the tests but I think that's a completely valid requirement.
There was a problem hiding this comment.
So something like pre-populating the fork cache with the forks that exist, or possibly just checking if the temporary fork's values are the same as the template fork's?
There was a problem hiding this comment.
Yes exactly, that would be even better, if the template already matches the values, just return the template.
|
Found the issue on why we are currently failing to fill tests for BPO1: We are calling So we might need to calculate |
Are we failing to fill? It should be running in CI with the tox change I think |
|
This PR changes |
marioevz
left a comment
There was a problem hiding this comment.
LGTM, thanks for this needed change :D
Only downside is that the startup time for fill went up since we do the copy of the template regardless of BPO values:
===================================================== 48 passed, 10 warnings in 116.29s (0:01:56) ======================================================
from:
=========================================================== 48 passed, 10 warnings in 5.05s ============================================================
Added a P-High label to #1864 based on this.
🗒️ Description
This pull request hooks up the new fork tool to the
Hardforkclass, uses that integration to generate new forks when the blob parameters are changed by the tests.🔗 Related Issues or PRs
closes #1453
Cute Animal Picture