ci(workflows): refactor and improve build perf

[sambacha]

trafficstars

Motivation

• CI build time improvement.
• Leverage new features to speed up time drastically.
• Additionally, the existing actions-rs are not maintained, they are over two years old with no updates and actually have genuine security issues.

rust nightly (side note)

CARGO_UNSTABLE_SPARSE_REGISTRY is only available nightly I will time the differences

The performance improvement for clients should be especially noticeable in CI environments, particularly if no local cache of the index exists.

sparse index rfc ref

Solution

All these GitHub Actions are drop in replacements, meaning they take the same arguments/params.

-        uses: actions-rs/toolchain@v1
+        uses: dtolnay/rust-toolchain@v1

Use fixed shared-key across workflows to persist cache across CI

-       - uses: Swatinem/rust-cache@v1
+      - uses: Swatinem/rust-cache@v2
+       with:
+        shared-key: cache-ci-
+          cache-on-failure: true

Alternative for caching

CI could do this as an alternative:

- uses: actions/cache@v3
  with:
    path: |
      ~/.cargo/bin/
      ~/.cargo/registry/index/
      ~/.cargo/registry/cache/
      ~/.cargo/git/db/
      target/
    key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}

[onbjerg]

Seems ok wrt the toolchain action, the other one I don't really see a benefit since both of them are just wrappers around calling cargo, there isn't really a lot to maintain and it is working fine currently.

Wrt cache keys I'd be extra careful that we don't accidentally poison the cache of other jobs that would then lead to errors

[sambacha]

Seems ok wrt the toolchain action, the other one I don't really see a benefit since both of them are just wrappers around calling cargo, there isn't really a lot to maintain and it is working fine currently.

Wrt cache keys I'd be extra careful that we don't accidentally poison the cache of other jobs that would then lead to errors

yup, Ill make some test for this cache and make the relevant changes to align with you and @mattsse comments

[gakonst]

it's not obvious to me that these changes improve perf from looking at the times above, so erring towards using the standard toolchain is better imo.

[sambacha]

it's not obvious to me that these changes improve perf from looking at the times above, so erring towards using the standard toolchain is better imo.

There is no standard toolchain: they are unmaintained.