-
Notifications
You must be signed in to change notification settings - Fork 212
show in-progress builds in build queue & build-list pages #2533
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
dc74322
to
a9dc5b0
Compare
a9dc5b0
to
f19952a
Compare
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? |
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 |
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. |
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 |
064378c
to
4d37ada
Compare
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.