Display reported build information in a badge and on crate version pages

[carols10cents]

This goes with rust-lang/cargo#3627. @shepmaster worked on these too :)

This PR adds a table that stores recorded crate version, rust version, target, and pass/fail as reported by crate owners using the cargo publish-build-info command.

The purpose is to enable crate authors to automatically report to potential crate users on the Rust version and platform compatibility of each version of the crate.

There's documentation in the cargo PR for doc.crates.io about how this feature is intended to work.

The badges, as described in that documentation, will display the latest version of the most stable channel that reported any pass results for the max version of that crate. Here's what that will look like, including the hover text:

Stable:

Beta:

Nightly:

Each crate version page will display more detail, currently it's not very pretty and it's not all of the possible information that collection supports. It's in a new section above the download stats graph, that has a table showing the most recent stable, beta, and nightly with any reported results for the Tier 1 platforms using 64 bit architectures:

Some enhancements to the display that we've thought about but haven't implemented yet:

• Have dropdowns for all the available versions for each channel
• Have a dropdown to select from additional targets
• Show icons or badges or colors instead of or in addition to the table
• Have a totally separate page with lots more detail shown all at once

We also thought about, but didn't implement:

• Ember tests for the UI
• Adding a different API token that would only be valid for publishing build info
• Showing the max version badge on crate page in the sidebar
• Allowing overwrite of a particular build_info row in case of mistakes if you're reporting build info manually

We're excited to hear what anyone thinks, and of course happy to answer questions or make modifications!

[alexcrichton]

I'd guess that overwriting is desired, right? That way if you have a flaky test and rerun the builds it'll appear working?

[carols10cents]

Ah, we can change this to make overwriting the default, definitely.

I think we were thinking about the case when you're working on the next version of a crate on the master branch, but you haven't bumped the version yet, you wouldn't want to overwrite the released version's build results with the master branch. We hadn't yet gotten to the realization that you could run things on travis on the push of a new tag... as long as everyone sets their CI up that way, overwriting should be fine.

And then that gets rid of the need to add an --overwrite flag to cargo, so I'm into it!

[alexcrichton]

This looks amazing, thanks so much @carols10cents and @shepmaster!

I'm noodling a bit about the UI and the best way to display this information. I'm not sure how useful a stable/beta/nightly matrix is in practice if we're trying to answer questions like:

• Does this crate build on stable?
• Does this crate work on Windows?

I think it'd be great to have a view with the full matrix somewhere, but maybe the main page could just say the version requirement of Tier 1 platforms? Basically says "works on $channel on $platform_list" (or something like that)

Although I do like data matrices, so I'm not entirely sure. Curious what you guys think!

(also cc @rust-lang/tools, exciting changes!)

[carols10cents]

I'm noodling a bit about the UI and the best way to display this information. I'm not sure how useful a stable/beta/nightly matrix is in practice if we're trying to answer questions like:

Does this crate build on stable?
Does this crate work on Windows?

I think it'd be great to have a view with the full matrix somewhere, but maybe the main page could just say the version requirement of Tier 1 platforms? Basically says "works on $channel on $platform_list" (or something like that)

Yeah I'm not sure, we can mock up a few different things if you'd like. We initially just had stable and nightly, but it felt weird to ignore beta, and that could be a sign that a crate might work on stable soon, if it works on beta and nightly but not stable.

Some people might want to know if the crate works on stable because they only work with stable, same with nightly. Some might want to know if it works on stable and nightly because they're working on a crate that they're trying to offer both to people who work with stable and nightly.

I also envisioned this helping answer the question of "which version of nightly did this version of the crate last work with?" That would require using nightli.es too though, OR travis's new cron feature, but the cron feature only lets you build every day with a particular branch, not a tag right now, as far as I can tell. I'll investigate this setup some more, to see if the short summary display should try and serve this use case.

And I'll try making a page displaying all build info we have for a crate version :)

[carols10cents]

Ok, I've got some mockups:

Denser on the crate page

First up is trying to give the answers to "Does this work on stable and/or nightly?" and "Does this work on windows?" more succinctly. I decided to try moving this to the sidebar on the crates page, where a lot of the other metadata is:

This is just a mockup for now, if people like this direction, I'll tighten up the alignment, give the icons nice alt text, and uuhhhh actually hook it together with the data. Icons are from devicons and are MIT licensed.

More info on a separate page

This is where you'd go if you clicked the "More build info" link in the previous mockup. I'm imagining a table for each channel, maybe showing the last 3 versions in that channel reported on, and then having a toggle to show the whole table (I could see nightly getting long, we could also cap that).

I just threw in emoji for now, if people like this direction I'd find nicer SVG icons.

WDYT?

[shepmaster]

I like the sidebar version, seems pretty clean to me!

I've a feeling that the detailed build info page has the potential to grow to have a lot of data — I'd love to be able to show "this builds on AVR", for example. I can also see there being a good amount of builds - even "just" release builds could have almost 20 data points by now, and nightly and beta could have even more... I'm not sure what the best solution for packing that much information in would be.

[nrc]

Both look good to me. For the dense view, could we indicate the variance (i.e., could be "1.14 and later" or "1.14 and earlier" or "1.14 - 1.16"). Do we even have that information?

For the detailed view, I feel that in a years time there are going to be a lot of version numbers that most users don't care about - could we show a subset initially and expand for all of them?

[alexcrichton]

@carols10cents looks great to me!

[carols10cents]

Blocked on me resolving the conflicts and implementing the proposed interface.