add simple "deployment pending" marker 20 minutes after a build

[syphar]

This is the first workaround for #1877 , showing what I imagined as a visible marker shortly after a build.

Looks like this when all is fine:

And like this when the deployment is too recent:

[syphar]

cc @jyn514 @jsha what do you think? Would that help crate maintainers understand what's going on?

Anyone for review?

[jsha]

The icon looks decent. I think it would also be useful to change the timestamps to say "x minutes ago".

Also, can we have different icons and tooltips for "queued", "building", and "deploying"?

And perhaps the deploying tooltip should say "it may take up to 15 minutes for this version to be visible to everybody" so people know how long to wait before e.g. announcing a new version with a link to latest.

[syphar]

The icon looks decent. I think it would also be useful to change the timestamps to say "x minutes ago".

Where exactly are you missing this?

Also, can we have different icons and tooltips for "queued", "building", and "deploying"?

• "queued" would be only needed for the build-queue page since these releases won't be shown in the other pages. Or would you just add the same icon for all lines on that page?
• "buildling" would involve starting to track "in progress" as a state on the queue table, and also would only be shown on the build-queue page.

IMO both could be seen as a separate issue since these would only touch the build-queue page which we're not touching in this PR. Or am I missing something?

And perhaps the deploying tooltip should say "it may take up to 15 minutes for this version to be visible to everybody" so people know how long to wait before e.g. announcing a new version with a link to latest.

I updated the tooltip.

[syphar]

there is also #1011 as an open topic where we could start adding crates that are currently built to pages.

[jsha]

Where exactly are you missing this?

I was going off the screenshot, which only shows dates; but I see on the actual homepage there are "time ago" markings.

"queued" would be only needed for the build-queue page since these releases won't be shown in the other pages. Or would you just add the same icon for all lines on that page?
"buildling" would involve starting to track "in progress" as a state on the queue table, and also would only be shown on the build-queue page.

From a user perspective, a crate goes through several steps: published; queued; building; deploying; deployed. It sounds like our database doesn't currently support showing all of those steps, which is fine. But if https://docs.rs/releases and https://docs.rs/ only show crates that have finished all their building steps, why is "deploying" not considered one of those steps? In other words, why show crates as finished when they still have to be deployed?

What if we combined the "recent" and "queue" pages? Then we would have one page that shows a list of recent activity, with most recent (unbuilt, queued) stuff at the top, and less recent (built) stuff at the bottom, and an icon next to each showing whether it's queued, deploying, or deployed?

Stepping back a little: what is the intended audience of the "recent releases" list? Is it for docs.rs devs to ensure everything is going smoothly? Is it for crate authors to check whether their crate got built?

[Nemo157]

I think we might want different behavior for the two locations showing this list.

The one on the homepage feels like just a flashy "look at what's happening" thing to me, not really with a specific usecase in mind. For that I think we might want to filter out "not yet deployed" releases and leave it looking like it currently does.

The "All releases" page (https://docs.rs/releases) feels like it's more targeting crate authors, as you say as a way to see whether their crate got built. For that showing "not yet deployed" releases makes sense, as otherwise the crate disappears off the queue page and doesn't appear here again for 20 minutes. We do also show failed crates in this list, so we probably want to change the ✔️ to a ❌ or ⚠️ when the build has failed and invalidation has completed.

---

What if we combined the "recent" and "queue" pages? Then we would have one page that shows a list of recent activity, with most recent (unbuilt, queued) stuff at the top, and less recent (built) stuff at the bottom, and an icon next to each showing whether it's queued, deploying, or deployed?

The main problem I see with this right now is how big the queue gets sometimes, the natural ordering would be to invert the queue order compared to what it is now, so the top of the queue is adjacent to the recently built releases in the middle of the page. But that would sometimes leave that transition point well below the fold, a few hundred rows down. If we can get build capacity/scalability up enough to keep the queue <20 items at all times then it would work better.

---

Another alternative is we could just integrate the "deploying" status onto the queue page. Filter these releases out of the recent releases list in both locations, and add them as a section on the top of the queue so we have (deploying, building, queued) in order on that page (though without any way to add a marker on building currently).

[jsha]

Another alternative is we could just integrate the "deploying" status onto the queue page. Filter these releases out of the recent releases list in both locations, and add them as a section on the top of the queue

This seems reasonable to me!

[syphar]

@jsha @Nemo157 this is ready for another look:

• the homepage doesn't have the icon any more, and also filters releases not deployed.
• we have a "build failed" icon for the other release lists
• the message for "deployment pending" was updated

[syphar]

I updated the view so we don't show binary crates as build failure.

What do you think? @Nemo157 @jsha ?
Or should we use a different icon for these?

[syphar]

I'm happy to add anything that might be missing, this is the only thing holding us back from actually activating the full page caching.

[jsha]

This looks great and I've tested it locally.

[jyn514]

Another alternative is we could just integrate the "deploying" status onto the queue page. Filter these releases out of the recent releases list in both locations, and add them as a section on the top of the queue

I also like this idea, it keeps the info on the queue which is where people already look to see where their releases are (and we already link it in the FAQ: https://docs.rs/about)

[syphar]

Another alternative is we could just integrate the "deploying" status onto the queue page. Filter these releases out of the recent releases list in both locations, and add them as a section on the top of the queue

I also like this idea, it keeps the info on the queue which is where people already look to see where their releases are (and we already link it in the FAQ: https://docs.rs/about)

thanks for the feedback :)

do you mean showing these on the queue-page instead of on the releases-pages? Or additionally?

When this is live (and after my vacation) I was planning on using the CloudFront API to use the actually active invalidations, which could also be the moment I could add them to the queue page.

[syphar]

forgot to mention you @jyn514 (not sure if you would see the question otherwise :) )

[jyn514]

I'm not sure how many people are looking at the releases page; don't have a strong opinion on whether to show it there or not. But I do think showing it on /queue is important.

[syphar]

closing this until further notice,

will check this again after the axum migration & the cdn batching is done