jonhoo / rust-ci-conf Goto Github PK

What is the license of this repo? Just wanted to make sure I could use this in a project with Apache 2.0 OR MIT.

In my example I added the dependency trybuild 1.0.85 while running on stable (1.73.0).
And all tests work fine.
The msrv check on github however does fail with:

Run cargo check
  cargo check
  shell: /usr/bin/bash -e {0}
  env:
    CARGO_INCREMENTAL: 0
    CARGO_TERM_COLOR: always
    Updating crates.io index
error: failed to select a version for the requirement `once_cell = "^1.9.0"`
candidate versions found which didn't match: 1.17.2, 1.17.1, 1.17.0, ...
location searched: crates.io index
required by package `trybuild v1.0.85`
    ... which satisfies dependency `trybuild = "^1.0.85"` (locked to 1.0.85) of package `private v0.0.0 (/home/runner/work/private/private)`
Error: Process completed with exit code 101.

As it turns out: once_cell 1.18.0 was added in the Cargo.lock, which is not compatible with the rust 1.58.1 (my msrv).

Running a cargo update before cargo check does the trick, as it downgrades it:

Run cargo update
    Updating crates.io index
    Updating once_cell v1.18.0 -> v1.17.2

Or are you running locally the msrv compiler, if yes simply close this request.
I'm happy to write a PR if this is wanted.

Edit: maybe it's not as good idea as I thought because it takes like 5 minutes to do the update (every run).

If the Cargo.toml contains only a workspace then the sed part does not help.

I don't know enough about sed to create a patch ,but if it's changed to
"insert before first features or workspace"
then it should work just fine.

I wonder why you use --locked with cargo test in inside jobs, even if respecting the lockfile is the default behavior.
To my knowledge, only cargo install don't respect the lockfile
I see your great video about how to set up CI and even some extra explanations you gave on twitter

--locked may seem over-zealous (compared to leaving it off) since Cargo will respect the lockfile without it. But otherwise your lockfile will be allowed to drift with respect to your declared dependencies, losing its effect (avoiding CI failures unrelated to PR changes).

but I still struggle to understand why. Could you please elaborate on this?

The safety workflow can run more sanitizers, such as memory and thread sanitizer, like crossbeam does.

As you can see here codecov - imap sort.rs, llvm-cov includes the test lines in the total coverage percentage.

This will increase the total percentage since the test lines are counted as covered. Other implementations like cargo-tarpaulin with llvm coverage excludes those test. Do you think those test lines should be skipped or kept?

An alternative could be the following:

diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
index c675b38..03fff3f 100644
--- a/.github/workflows/test.yml
+++ b/.github/workflows/test.yml
@@ -75,13 +75,13 @@ jobs:
         uses: dtolnay/rust-toolchain@stable
         with:
           components: llvm-tools-preview
-      - name: cargo install cargo-llvm-cov
-        uses: taiki-e/install-action@cargo-llvm-cov
+      - name: cargo install cargo-tarpaulin
+        uses: taiki-e/install-action@cargo-tarpaulin
       - name: cargo generate-lockfile
         if: hashFiles('Cargo.lock') == ''
         run: cargo generate-lockfile
-      - name: cargo llvm-cov
-        run: cargo llvm-cov --locked --all-features --lcov --output-path lcov.info
+      - name: cargo tarpaulin
+        run: cargo tarpaulin --engine llvm --locked --all-features --out lcov
       - name: Upload to codecov.io
         uses: codecov/codecov-action@v3
         with:

This implementation could have other disadvantages than llvm-cov, but the coverage should be more representative of the real code. Here and example with the above codecov coverage

I was watching your most recent Rust Nation talk and you mentioned automated benchmarking to detect regressions. I was wondering if you had any CI configs that you could upload to this repo, if you could be so kind? If not maybe something based on what they have in rusttls would be a good idea.