Use disk space optimization for benchmark checks

[sea212]

What does it do?

• Adds a config parameters to the benchmarking scripts that when set does cargo clean between the standalone and parachain benchmark runs

What important points should reviewers know?

• Potential solution to fix broken CI pipekine due to insufficient amount of disk space.

Is there something left for follow-up PRs?

What alternative implementations were considered?

Are there relevant PRs or issues?

References

[codecov-commenter]

Codecov Report

All modified lines are covered by tests ✅

Comparison is base (e2cacc0) 93.49% compared to head (ab300cb) 93.37%.
Report is 8 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1129      +/-   ##
==========================================
- Coverage   93.49%   93.37%   -0.13%     
==========================================
  Files          94      114      +20     
  Lines       28645    31680    +3035     
==========================================
+ Hits        26783    29582    +2799     
- Misses       1862     2098     +236     

Flag	Coverage Δ
tests	93.37% <ø> (-0.13%)	⬇️

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

see 51 files with indirect coverage changes

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

[Chralt98]

So this is an optimisation to get the LLVM ERROR: IO failure on output stream: No space left on device away? But it's still there in your CI.

But in general if we have the first cargo build:

cargo build \
    --profile=$PROFILE \
    --features=runtime-benchmarks,$ADDITIONAL_FEATURES \
    --bin=zeitgeist

And the second cargo build is:

cargo build \
    --profile=$PROFILE \
    --features=runtime-benchmarks,parachain,$ADDITIONAL_FEATURES \
    --bin=zeitgeist

then we have essentially the same crates to compile, except for the second run there needs to be the feature parachain compiled. So the second cargo build adds additional compilation overhead (artifacts). So, can you explain what cargo clean gets done in this case? I think it even slows down compilation time, while having the same disk space required.

[Chralt98]

Do benchmark runs produce artefacts in the target folder?

[sea212]

Yes, the build time significantly increases since many build files that are shared are removed. The idea was to exchange disk space for build time to make GitHub hosted runners capable of finishing the job.

It seems like that approach does not lead to GitHub hosted runners being capable to produce results in time. Looks like now the issue is that it just takes too long.

Closing in favor of #1134