ci: add sccache to speed up ci build

[xxchan]

e.g., the unit job takes 10min in total, and build takes 5min. So I think we can introduce cache to speed it up.

[xxchan]

The latest version is 0.0.7, but I only see 0.0.4 listed here https://github.com/apache/infrastructure-actions/blob/main/approved_patterns.yml

[liurenjie1024]

Should we consider submit a pr to ask infra team to update approved pattens? cc @Xuanwo

[kevinjqliu]

heres the original issue for 0.0.4

https://issues.apache.org/jira/browse/INFRA-25525?jql=text%20~%20%22sccache-action%22

[xxchan]

comparison:
before: https://github.com/apache/iceberg-rust/actions/runs/12394303990

after: https://github.com/apache/iceberg-rust/actions/runs/12395899529?pr=824

Seems not as good as expected, but generally reduced >1 min. UT reduced >2 min

[xxchan]

Seems caused by Mozilla-Actions/sccache-action#50

[Fokko]

Windows build took even longer after the change 🤔

[xxchan]

The cache hit rate was very low, and there's plenty of Cache write errors (I guess it's rate limit Mozilla-Actions/sccache-action#50).

After running it for more times to warm up the cache, it should perform better.

[xxchan]

I found an alternative to sccache: swatinem/rust-cache@v2 (also approved by ASF)

They work differently:

• sccache writes/reads cache for each individual build artifact.
• rust-cache has a large cache for all dependencies (keyed by Cargo.toml and Cargo.lock)

It's possible that rust-cache works better with GHA cache. But we will need to check in Cargo.lock (currently ignored) to make it work better. (We can consider doing it, and it has other benefits like a reproduciable build for CI and all developers.)

---

IMO sticking with sccache is also not too bad as it seems simpler to me

[liurenjie1024]

I found an alternative to sccache: swatinem/rust-cache@v2 (also approved by ASF)

They work differently:

• sccache writes/reads cache for each individual build artifact.
• rust-cache has a large cache for all dependencies (keyed by Cargo.toml and Cargo.lock)

It's possible that rust-cache works better with GHA cache. But we will need to check in Cargo.lock (currently ignored) to make it work better. (We can consider doing it, and it has other benefits like a reproduciable build for CI and all developers.)

IMO sticking with sccache is also not too bad as it seems simpler to me

I'm not a big fan of checking in Cargo.lock as it's an antipattern for library. I think sscache is good enough.

[liurenjie1024]

Thanks @xxchan for this pr! Personally I have no strong opinions about this, as it doesn't seem to improve performance too much, while rate limit error may even slow down the test. But in general it's not bad for rust project. I'm looking forward to hear others' ideas. cc @Xuanwo @Fokko @kevinjqliu

[xxchan]

To be more precise about the performance gain: For unit test: previous compile time is 5m 06s, now 2m 35s

cache stats:

(non-cacheable calls could be the bottleneck in this case. They are usually some dependencies with build scripts e.g., C++ dependencies, and are slow to build. I guess rust-cache may also perform better for them)

[xxchan]

I'm not a big fan of checking in Cargo.lock as it's an antipattern for library

Just FYI that it's not considered an antipattern any more https://blog.rust-lang.org/2023/08/29/committing-lockfiles.html

And e.g., opendal has it: https://github.com/apache/opendal/blob/main/core/Cargo.lock

I don't have strong opinion and I'm OK with both though.

[kevinjqliu]

Since this PR only affects CI and seems to be an overall improvement. I don't see any downside of including this

btw im not sure if everyone has access to apache INFRA jira, happy to open a ticket to allow the 0.0.7 version of the library

[Fokko]

The downside is additional complexity and maintenance. The Windows job takes the most time, and after the change it takes even more, so the maximum runtime gets worse, just the average runtime improves. I'm leaning toward what @liurenjie1024 is saying, and avoiding caching. Curious to learn what @Xuanwo thinks

[liurenjie1024]

I'm not a big fan of checking in Cargo.lock as it's an antipattern for library

Just FYI that it's not considered an antipattern any more https://blog.rust-lang.org/2023/08/29/committing-lockfiles.html

And e.g., opendal has it: https://github.com/apache/opendal/blob/main/core/Cargo.lock

I don't have strong opinion and I'm OK with both though.

Thanks for the reference, I wasn't aware of it.

Would you mind to have a try with rust-cache? I'm not sure about the difference and it would be better to make decision with actual pr and result.