[CI] duckdb-rs does not seem cached

[eitsupi]

After db35006, CI takes very long time.
The latest run results show that it took orver 20 minutes to run the integration test (test-rust (ubuntu-latest, x86_64-unknown-linux-gnu)).
https://github.com/PRQL/prql/actions/runs/5250151067/jobs/9483781674

Previously, it seemed to take 4 minutes.
https://github.com/PRQL/prql/actions/runs/5238573921/jobs/9457591558

[max-sixty]

I wiped them with gh actions-cache list | rg rust | choose 0 | rargs gh actions-cache delete {} --confirm, let's see whether that helps. Generally the cache action has been very good, but possibly something happened on that run...

[max-sixty]

I'm still seeing this. I'm not sure why duckdb 0.8.0 doesn't cache. We could try reverting duckdb and see whether that's it (but we'd need to revert the stdlib change too). We could also try reverting some of the CI changes.

Trying ideas is difficult, because to really try something you need to:

• Make a change
• Delete the cache (unless it changes the cache key, e.g. with a dependency change)
• Merge the change
• Wait for the cache to build
• Re-run the workflow and check it uses the new cache

Sorry that this is causing trouble. We already spend lots of time on devops so it's unfortunately that now it's not in a great state. I need to sign off for the evening and don't have as much time to work on PRQL this week / weekend, but will think more about what could be causing it.

[eitsupi]

Thanks for taking a look at this.

DuckDB 0.8.1 was released just a few minutes ago, so the duckdb-rs update will probably occur again this weekend.
Let's see what happens there.

[eitsupi]

PS, definitely speeded up the compiling of the test. Thanks!

Only Clippy build time is long now......

[max-sixty]

PS, definitely speeded up the compiling of the test. Thanks!

Only Clippy build time is long now......

Yeah, ensuring every command has a --target (or none of them) fixed most things. I'm not sure why duckdb is straggling there.

I don't think it's clippy specifically though, I think if we remove the clippy step that won't help — clippy is compiling things first — so it would just compile later on.

[max-sixty]

Sorry, I opened a duplicate at #2870. Because I've linked to that in other repos, if it's OK, I'll close this one in favor of that.