add test into ci

[asukaminato0721]

This may has some problems about floating point number. Let's try it.

[asukaminato0721]

---- cosine_annealing::test_lr_scheduler stdout ----
thread 'cosine_annealing::test_lr_scheduler' panicked at 'assertion failed: `(left == right)`
  left: `[0.1, 0.09045084971874769, 0.06545084971874847, 0.03454915028125373, 0.009549150281252953, 0.0, 0.00954915028125269, 0.034549150281252376, 0.0654508497187476, 0.09045084971874953, 0.10000000000000367]`,
 right: `[0.1, 0.09045084971874785, 0.06545084971874875, 0.034549150281253875, 0.009549150281252989, 0.0, 0.009549150281252692, 0.03454915028125239, 0.06545084971874746, 0.09045084971874952, 0.10000000000000353]`', src/cosine_annealing.rs:76:5

linux and macos have different floating point implementation. So instead of assert_eq, we need to use something like eps.

[asukaminato0721]

it seems that linux cache is empty

Run actions/cache@v3
Received 211 of 211 (100.0%), 0.0 MBs/sec
Cache Size: ~0 MB (211 B)
/usr/bin/tar -xf /home/runner/work/_temp/c5ec5a79-37aa-4d5d-93e5-701f2ffcc443/cache.tzst -P -C /home/runner/work/fsrs-optimizer-burn/fsrs-optimizer-burn --use-compress-program unzstd
Cache restored successfully
Cache restored from key: Linux-rust-release-v5-

[Colerar]

Currently, the CI configuration seems a bit redundant, we can only run cargo fmt and cargo clippy in Ubuntu, and run test for all targets, this can reduce the CI execution time.

And it may be best to use https://github.com/marketplace/actions/rustup-toolchain-install to ensure all tool versions are aligned and up to date.

[dae]

#33 should fix the caching issue. Agreed that pinning Rust is a good idea, but rust-toolchain.toml is a better choice than a GitHub action, as it also works when people test locally.

[dae]

Regarding tests on multiple platforms, and building in release mode:

• Having a fast feedback cycle in CI checks is good for developer productivity, so ideally at least one of the platforms will a) compile in debug mode and b) not run any expensive tests.
• The current tests based on the sample .anki21 file are good for ensuring we don't make regressions as we refactor, but it's not ideal to have to download a file, compile in release mode, and wait for the processing to finish. I'd recommend this test file is either opt-in with an env var so it is only used for local testing, or the test is run in a separate workflow so that there's still a fast fmt+clippy check.

[dae]

I've pushed some changes into #32 that uses the file to run the tests, but skips the training test, so things are still nice and fast when the cache is fresh. If you guys approve of those changes, maybe this PR could be adjusted to focus on separate workflows for running the tests on Mac/Windows, and maybe a separate one for running the training too.

[asukaminato0721]

If you guys approve of those changes, maybe this PR could be adjusted to focus on separate workflows for running the tests on Mac/Windows, and maybe a separate one for running the training too.

I am ok with that :) ，feel free to modify this PR.

[dae]

Linux 34s, Mac 1m, Windows 3:30. 😅