show in-progress builds in build queue & build-list pages#2533
show in-progress builds in build queue & build-list pages#2533syphar merged 8 commits intorust-lang:masterfrom
Conversation
github-actions
Bot
added
the
S-waiting-on-review
syphar
changed the title
syphar
force-pushed
the
in-progress-builds
branch
from
dc74322 to
a9dc5b0
Compare
syphar
changed the title
syphar
force-pushed
the
in-progress-builds
branch
from
a9dc5b0 to
f19952a
Compare
|
some screenshots: 
|
|
The position of the cog in the second screenshot seems weird, no? |
True... looking at the HTML I have no idea (yet) where this can come from. super odd |
|
I can take a look if you want. Can you host the webpage with its style somewhere? |
GuillaumeGomez
force-pushed
the
in-progress-builds
branch
from
2e27eb6 to
43a5212
Compare
|
I'll not merge this PR before I solved the new sentry errors / panics I'm seeing, that are regressions from #2467 |
syphar
force-pushed
the
in-progress-builds
branch
2 times, most recently
from
4dc8df7 to
98b8611
Compare
|
Hi @syphar. Is the PR ready for a new review? |
|
hey :) not yet, but it's next on my list to rebase & re-test. |
syphar
force-pushed
the
in-progress-builds
branch
from
98b8611 to
c5573e9
Compare
|
@GuillaumeGomez IMO this is ready for another review. I rebased, added some fixed, and did a short manual test of some cases. |
|
oh, I see some test failures from my template-filter change, fixing them now |
|
just saw something else I want to change, need to figure out details: when the latest build is in progress, I think a user probably wants to see the docs for the previous build. edit: i mean, for the semver match, not for the exact query |
syphar
requested review from
GuillaumeGomez
and removed request for
GuillaumeGomez
syphar
force-pushed
the
in-progress-builds
branch
from
064378c to
4d37ada
Compare
syphar
added
S-waiting-on-deploy
2 participants
Resolves #1011.
( last piece IMO)
this will start showing in-progress builds mainly in:
on top of already redirecting to the build-list when someone tried to access a new in-progress crate.
I'm not 100% certain if we will open up the handlers to some new errors when called on a in-progress crate, but IMO we just have to see and act when there are errors.
One caveat:
Perhaps I'm missing something, but I believe we will have an issue around server restarts and in-progress builds. When we stop / restart our server process we will just stop building without updating our build-status in the database. So we might have "orphaned" in-progress builds.
I'm not sure yet how to solve this the best way, I think the correct solution is a proper graceful shutdown involving rustwide doesn't feel simple. The shutdown would also have to be per build-server, so autoscaling buildservers in the future doesn't reset the build status for builds on other build-servers.
A workaround if we see this happening would probably be to manually reset the build-status for in-progress builds in our deploy-script.