Description
Currently when there is an issue like a build failure crate authors need to wait till the build has been run then visit the docs page to see whether it was successful or not. Commonly instead they first discover the issue when one of their users tries to visit the docs and sees the failure and notifies them (or us directly). It would be nice if we could more proactively surface these build failures (and potentially other warnings) to the authors.
One constraint I want to keep the design under is that we do not store any server-side data to try and do something like a push notification to the users; potentially in the future there could be some opt-in integration with crates.io if they get some kind of push notification system.
Proposed design:
- Add a new endpoint like
/crate/:crate/warnings.jsonthat provides warnings for the crate (e.g. latest version failed to build, latest version built but some targets failed, anything else we might want to add in the future) - Add a small drop-down widget to the top-bar for showing these warnings
- in the widget have a button to add the current crate to the list of crates to check, this simply stores the crate name into local storage
- on page load (maybe with a delay between re-requests stored in local storage) grab the list of subscribed crates and poll their warnings endpoints, showing some kind of notification bubble in the widget if any have a warning
- Potentially: have some integration with crate owners, so you can subscribe to see all warnings for crates you own (or maintain through a proxy owner like
rust-lang-owner) without having to manually go subscribe when you publish a new crate (this might have issues around cacheability, while the/crate/:crate/warnings.jsoncan be heavily cached in the CDN).