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

set up CI #2

Open
Eh2406 opened this issue Jan 2, 2024 · 2 comments
Open

set up CI #2

Eh2406 opened this issue Jan 2, 2024 · 2 comments

Comments

@Eh2406
Copy link
Member

Eh2406 commented Jan 2, 2024

I would like to make sure that all the code compiles and that the portion of tests that can be run quickly pass. Testing crates.io takes 5cpu days, fuzzes will run as long as you let them, so cannot be run on CI merge.

@mpizenberg
Copy link
Member

Would it be hard to randomly select a subset of roughly 1K versions on each run? I guess there would need to be a fast index to look at.

@Eh2406
Copy link
Member Author

Eh2406 commented Jan 5, 2024

I got annoyed with waiting to scan the index on every build. So it now does the analysis based on pre-computed files on disk. And there is a command line argument to generate the files from the index. This makes local development a lot faster. And the files are (just barely) small enough to commit. So retrieving versions to test is no longer a CI blocker.

Figuring out sampling strategies seems reasonable. A subset of inputs, or a subset of tests. For example almost all of the runtime is spent on intersections, so testing only contains and complement in CI might be fast enough.

Similarly we spent a lot of time testing if versions like 0.1.0 match >5.0.0, we could use bounding_range to skip over versions that have no chance of being relevant.

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

No branches or pull requests

2 participants