Add basic smoke tests for docs.rs

[jyn514]

After the fiasco with #519, I figured I'd write this before making any new PRs.

This is very much an integration test, not a unit test. It should catch things like 'docs.rs doesn't build with an empty .rustwide cache', but because of that, it takes a very long time to run (~45 minutes on Github Actions). I tried to set up caching, but the permissions weren't working quite right: actions/cache#131

This runs reasonably quickly locally, ~5 minutes if everything is cached.

This depends on the changes from #523 (because otherwise the tests take about 25 minutes locally). Either that PR should be merged first or it should be closed when this one is merged.

Finally, this also uncomments two #[ignore] tests that were passing. The rest are left commented since they're currently failing.

There should be no change in behavior to the production server, since it doesn't run builds with -s anyway.

r? @pietroalbini

[pietroalbini]

So, while as a stopgap solution I feel this is ok, I don't want to rely on this too long:

• To test the builder works, we shouldn't rely on real world crates, as they take too long to build. For rustwide and Crater I created dummy crates specific to the tests I was writing, for example rustwide's out-of-memory crate.
• To test the webserver works, we shouldn't build real crates, but just "simulate" builds by adding stuff to the database directly.
• We should move away from bash scripts, and integrate the whole thing with cargo test.

Also, fyi, uploading the cache failed. If you remove the caching from GitHub (also because we're surely over the 400MB limit) we can merge this.

[jyn514]

Removed the cache.

To test the builder works, we shouldn't rely on real world crates, as they take too long to build. For rustwide and Crater I created dummy crates specific to the tests I was writing, for example rustwide's out-of-memory crate.

The longest part of the build seems to actually be initializing Rustwide, not building the crates. I think building dummy crates will help, but I'm not sure by how much.

To test the webserver works, we shouldn't build real crates, but just "simulate" builds by adding stuff to the database directly.

That's a really good idea.

We should move away from bash scripts, and integrate the whole thing with cargo test.

+1

[pietroalbini]

The longest part of the build seems to actually be initializing Rustwide, not building the crates. I think building dummy crates will help, but I'm not sure by how much.

Is WorkspaceBuilder::fast_init called when executing tests? We shouldn't enable it on production, but when running tests it should help a lot. rustwide's CI takes ~11 minutes to initialize a workspace and run tests in it.

[jyn514]

Is WorkspaceBuilder::fast_init called when executing tests?

No, because this doesn't change any of the code. Maybe we could set fast_init based on an environment variable? That would also be useful for local development.

[pietroalbini]

Maybe we could set fast_init based on an environment variable? That would also be useful for local development.

Yeah.

[jyn514]

Added fast_init. It still takes ~45 minutes :/

[pietroalbini]

Can we convert this to the new testing tools?

[jyn514]

Yes, I can do that sometime this week.

[jyn514]

Making a list of things to do:

• Make PRs for unrelated fixes
  • don't ignore DB cache if file cache is empty (Don't ignore DB cache if local cache is empty #523)
  • don't ignore passing tests
  • Do we want to have a FAST_INIT env var?
• Test that docs for binary crates redirect to /crate/:crate/:version
• Make sure that viewing source code works (with or without trailing slashes)
  • for rustdoc
  • for our source viewer
• 'Go to latest version' should keep the page and platform (+ misc, read existing tests)
• /std should redirect to https://doc.rust-lang.org/stable/std/

[jyn514]

Closing in favor of #570