Display reported build information in a badge and on crate version pages #540
Conversation
On a particular crate version's page.
For the latest crate version only, for the purpose of showing a badge on crate list pages.
On crate list pages. If the latest version builds on any stable version, show that it builds on stable. If not and it builds on any nightly version, show that. Otherwise, don't show any badge.
|
|
||
| if inserted == 0 { | ||
| return Err(human(format!( | ||
| "Build info already specified for {} v{} with {} and target {}", |
There was a problem hiding this comment.
I'd guess that overwriting is desired, right? That way if you have a flaky test and rerun the builds it'll appear working?
There was a problem hiding this comment.
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!
|
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:
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!) |
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 :) |
|
Ok, I've got some mockups: Denser on the crate pageFirst 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 pageThis 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? |
|
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. |
|
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? |
|
@carols10cents looks great to me! |
|
Blocked on me resolving the conflicts and implementing the proposed interface. |
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-infocommand.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
passresults 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:
We also thought about, but didn't implement:
We're excited to hear what anyone thinks, and of course happy to answer questions or make modifications!