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

Update Github Actions CI for the master branch #192

Merged
merged 6 commits into from
Jan 4, 2021
Merged

Update Github Actions CI for the master branch #192

merged 6 commits into from
Jan 4, 2021

Conversation

josephlr
Copy link
Member

@josephlr josephlr commented Jan 3, 2021

Fixes #181 and adds a bunch of stuff to the CI

  • Use -Z build-std=core instead of xbuild
  • Use Clippy configuration file, instead of manually whitelisting lints
  • Cleanup tests.yml
  • Faster binary downloads
  • Add minimal dependencies check
  • Add tests for custom feature
  • Build/Link for iOS
  • Run cross tests on aarch64 linux and Android
  • Link on Solaris and Netbsd
  • Test wasm code on Node, Chrome, Firefox
  • Test WASI
  • No need for RDRAND feature on VxWorks

The following TODOs will be done in a follow up PR:

  • Actually run the iOS binaries
  • Build/Run aarch64-apple-darwin binaries (aka "Apple Silicon")
  • Add emscripten tests

@josephlr
Copy link
Member Author

josephlr commented Jan 3, 2021

@newpavlov This is ready for review, let me know what you think.

Right now we will run 6 tests on macos-latest (4 for macos, 2 for iOS). Given that those CI jobs are the slowest to schedule, should we try to reduce the number of jobs? Maybe only test stable for macos?

@josephlr
Copy link
Member Author

josephlr commented Jan 3, 2021

Right now we will run 6 tests on macos-latest (4 for macos, 2 for iOS). Given that those CI jobs are the slowest to schedule, should we try to reduce the number of jobs? Maybe only test stable for macos?

I changed the test matrix to only run macos-latest tests for:

  • stable x86_64-apple-darwin
  • stable aarch64-apple-ios
  • stable x86_64-apple-ios

I don't think there's a huge advantage to testing things like 1.34, beta, etc... on multiple different OSes (as we mostly use these tests for code compatibility, not OS compatibility), so this should be fine.

Our entire CI now runs in < 3 minutes, with the build-std job being the last major bottleneck (as it has to build libcore 4 times in a row).

Copy link
Member

@newpavlov newpavlov left a comment

Choose a reason for hiding this comment

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

Looks good!

Do we still need the .cargo/config file? Also maybe it's worth to move test modules from src/ to tests/?

.github/workflows/tests.yml Outdated Show resolved Hide resolved
.github/workflows/tests.yml Outdated Show resolved Hide resolved
.github/workflows/tests.yml Show resolved Hide resolved
.github/workflows/tests.yml Show resolved Hide resolved
This allows us to automatically ignore lints that are
incompatible with our MSRV.

Signed-off-by: Joe Richey <joerichey@google.com>
- Cleanup `tests.yml`
- Add better binary downloads
- Add minimal dependancies check
- Add tests for `custom` feature
- Build/Link for iOS
- Run cross tests on aarch64 linux and Android
- Link on Solaris and Netbsd
- Test wasm code on Node, Chrome, Firefox
- Test WASI
- No need for RDRAND feature on VxWorks

Signed-off-by: Joe Richey <joerichey@google.com>
Most of the advantages from testing various Rust versions already come
from running those tests on Linux and Windows. There's very little
gain from also running these tests on macOS, while macOS jobs are the
slowest to schedule.

Signed-off-by: Joe Richey <joerichey@google.com>
Signed-off-by: Joe Richey <joerichey@google.com>
@josephlr
Copy link
Member Author

josephlr commented Jan 4, 2021

Do we still need the .cargo/config file?

This is what allows us to use cargo run/cargo test normally on wasm32-unknown-unknown and wasm32-wasi. The same effect can be achieved with environment variables, but I thought the .cargo/config was more idiomatic. I added a comment explaining.

Also maybe it's worth to move test modules from src/ to tests/?

Good idea, I did this in a separate PR, see: 28cafca

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.

Add CI for WASM targets
2 participants