Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extended CI suite #385

Draft
wants to merge 5 commits into
base: master
Choose a base branch
from
Draft

Extended CI suite #385

wants to merge 5 commits into from

Conversation

LucasFA
Copy link
Contributor

@LucasFA LucasFA commented Mar 2, 2024

Took me a while to get around to it, but finally there's something to show for it.

  • Set a MSRV in the Cargo.toml and a new MSRV job
  • Check OS specific features, both in MSRV and general CI job
  • Cache ./target/ and creates a CI profile to reduce its cache usage, though Swatinem does a good job already
  • Reorders calls to cargo clippy and test to have the quickest at the beginning

I also took the liberty of reordering the features in the Cargo.toml file, in decreasing number of dependencies, mostly. We can drop that.
New (action) dependencies: taiki-e/install-action@v2 and Swatinem/rust-cache

Reorder features (by number of dependencies)
Create CI profile, set MSRV
Switch CI cache to Swatinem, reorder CI steps

Swatinem is for starters just simpler to use and keys very sensitively.
It also eliminates unnecessary files from `./target/`, which might be a
good idea to cache with the now quite large number of jobs.

I reordered the features also somewhat in user importance (increasing).
The CI profile is primarily intended to reduce the size of the `./target/`
folder.

Reorder execution for speed/latency - clippy is fast.
@LucasFA LucasFA mentioned this pull request Mar 2, 2024
Copy link
Owner

@aome510 aome510 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have a few questions. Do you also know why the last job's name is weird?

image

@@ -12,7 +12,33 @@ env:
RUST_FEATURES: "rodio-backend,lyric-finder,media-control,image,notify,clipboard"
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realize once you surround the arguments with quotes, spaces can be used instead of commas. See my below suggestions

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then you also need to update this variable to use spaces

Comment on lines +22 to +25
- os: ubuntu-latest
OS_SPECIFIC_FEATURES: ",daemon, sixel"
- os: macOS-latest
OS_SPECIFIC_FEATURES: ",sixel"
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- os: ubuntu-latest
OS_SPECIFIC_FEATURES: ",daemon, sixel"
- os: macOS-latest
OS_SPECIFIC_FEATURES: ",sixel"
- os: ubuntu-latest
OS_SPECIFIC_FEATURES: "daemon sixel"
- os: macOS-latest
OS_SPECIFIC_FEATURES: "sixel"

msrv:
if: github.event.pull_request.draft != true
strategy:
fail-fast: false
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not fail-fast on this one?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that being a check rather than build or test, the job should be fast enough to not matter for a few seconds, and adds the feedback on whether it broke for every platform or not - likely would be a platform dependant dependency.
Though if keeping the MSRV for builds with all (compatible) features it would have to be bumped anyway.

@@ -12,7 +12,33 @@ env:
RUST_FEATURES: "rodio-backend,lyric-finder,media-control,image,notify,clipboard"

jobs:
rust-ci:
msrv:
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can msrv be put as a step of rust-ci instead to avoid code duplication between those two?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm seeing if the solutions in this discussion to reuse matrices can be applied in a simple way here. Notable possible problem is that they don't use the same matrices as it is right now.
That's your main concern I assume, though the checkout and install packages steps could be abstracted away into another workflow, too.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought you only need to move

- name: Install cargo-hack
  uses: taiki-e/install-action@cargo-hack

- name: Run MSRV check 
  run: cargo hack check --rust-version --package spotify_player --all-targets --profile ci --features "${{ env.RUST_FEATURES }} ${{ matrix.OS_SPECIFIC_FEATURES }}"

to be in rust-ci.steps.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I originally wanted to to have them as separate jobs in order to report these separately - at the end of the day, if it doesn't build in the current compiler that's a hard error, but breaking MSRV is salvageable, if anything by bumping the MSRV.

But we can do that, we would just have to check the log if it does break

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, one needs to check the action's logs if CI run fails anyway.

.github/workflows/ci.yml Outdated Show resolved Hide resolved
Cargo.toml Show resolved Hide resolved
Cargo.toml Show resolved Hide resolved
@LucasFA LucasFA marked this pull request as draft March 6, 2024 23:45
@LucasFA
Copy link
Contributor Author

LucasFA commented Mar 6, 2024

Alright I'm making this a draft - I'm trying to figure a way without repetitions but that keeps the jobs separate. As well as not being as complicated as that in that blasted discussion I linked earlier. I'm working on another (personal) branch - be back in a few days

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.

2 participants