Skip to content

Conversation

@delta1
Copy link

@delta1 delta1 commented Apr 24, 2025

Updates the CI workflow:

  • use ubuntu 22.04
  • split into separate jobs
  • use maintained rust github actions

delta1 added 2 commits April 24, 2025 21:10
ubuntu 22.04 was failing to run electrum.AppImage with the following error:

dlopen(): error loading libfuse.so.2
AppImages require FUSE to run.

Fix by installing libfuse2
@delta1
Copy link
Author

delta1 commented Apr 24, 2025

test-liquid (cache miss): 7 minutes
test-liquid (cache hit): 1 minute

@philippem philippem requested review from RCasatta and shesek April 26, 2025 13:06
@philippem philippem merged commit 181256b into Blockstream:new-index Apr 26, 2025
5 checks passed
@shesek
Copy link
Collaborator

shesek commented Apr 26, 2025

use ubuntu 22.04

👍

split into separate jobs

What was the rational for using separate jobs instead of separate steps?

It can run more quickly because the jobs run in parallel, however it seems that the savings aren't significant. Running the tests before this PR took 2m 51s, while with this PR it takes 1m 19s for the last test to finish. (with cache in both cases)

However, in our CI setup prior to this PR, it seems that a significant time was spent loading the cache - 1m 26s vs 13s with the new Swatinem/rust-cache action. The actual time it took to run the tests in serial steps was less than that, 1m 11s in total:

image

So with just a better caching strategy we could get most of the speedup gains of this PR, even without using separate parallel jobs. The most that could be saved by running in parallel is the difference between the serial execution time of 1m 11s and the last-to-finish test execution time of 45s -- a maximum of 26 seconds.

The drawback I see for separate jobs is that it complicates the workflow file, requires repeating the setup actions for each job and maintaining changes in multiple places. Reusing the setup actions would reduce this PR's workflow file by 21 LoC (~40%) and make maintenance easier.

(The setup duplication also requires more compute resources overall -- but I guess we don't really care about that since GH is footing the bill)

use maintained rust github actions

We were using an outdated version of actions/cache (which showed up a warning on the CI page), so it definitely make sense to update it. (and apparently were also using it wrong? loading the cache took unreasonably long)

However I'm a bit wary of using unofficial actions if there's no compelling reason to. Just last month there was a supply-chain attack against a widely used GitHub Action (CVE-2025-30066). Does Swatinem/rust-cache have an advantage over GH's official actions/cache (assuming its updated & properly configured for Rust/Cargo)? What does dtolnay/rust-toolchain get us vs calling rustup directly?

@delta1
Copy link
Author

delta1 commented Apr 27, 2025

It was more about fixing the broken CI than anything else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants