feat/ci: workflow adjustments to use rocksdb.a precompiled#1629
feat/ci: workflow adjustments to use rocksdb.a precompiled#1629
Conversation
drahnr
added
the
no changelog
drahnr
force-pushed
the
bernhard-rocksdb-ci-impro
branch
2 times, most recently
from
4e083ee to
3ef9d51
Compare
|
@Mirko-von-Leipzig this is going to conflict quite a bit with your refactor into a single file (in a "good way" in a sense) |
How would you like to go about it? I think after mine makes sense because it simplifies your diff here iiuc? But of course I'm biased 😁 I don't mind if you'd prefer to go ahead with this first. We could also forgo this PR entirely and see whether the caching changes are dramatic enough to not care about this? |
|
Please merge your's first, I'll do some comparison of cache+time afterwards |
drahnr
force-pushed
the
bernhard-rocksdb-ci-impro
branch
from
6384ded to
1c0af0d
Compare
There was a problem hiding this comment.
Do you think this is still worth adding to CI runs? Right now all large jobs here build on top of the build job which should already mean compiling this only once due to shared caching.
There was a problem hiding this comment.
I think we'd safe on link-time, but there is complexity penalty adding.
Haven't checked the "savings" if any just yet.
2 participants
Uses a static rocksdb library (
rocksdb.aon Linux, we only build on Linux), except forpublish-related CI runs.Why
We spend significant time on building the same artifact repeatedly, and
What
miden-node-util)rocksdb.astatic library, and use that in conjunction with the "right" env vars to skip build - we also skip caching rocksdb (C++) build artifacts which saves us a good chunk of cache, once used uniformly.Open questions:
cargo b -p librocksdb-sys@{{ version }} --lockedwe will build the exact same library, so we might want to unify the approach topublish-*workflows as well - I think we should