allow setting global alert from the database / CLI

[syphar]

I want to be able to set / remove the global alert without having to recompile / deploy.

Cases for this probably:

• queue length (I might automate this warning at some point)
• potential reduction of default targets due to build capacity (separate discussion, probably blog article & survey first?)

We cache the value for 5 minutes, so we won't have too many added database queries.

It will look like this, and be a link to the given link:

[GuillaumeGomez]

I think you're trying to fix two different problems here:

1. docs.rs issues
2. docs.rs changes

The first one needs to be there as long as the issue(s) are there. The second one being a notice, it should be discard-able by the user and attract attention a lot more. So your PR fits well for 1., but doesn't for 2. imo. 2. should most likely be a static element floating over the content.

What do you think?

[syphar]

I admit I didn't think much further than just making the old feature not hardcoded, so we can start showing something somewhere.

I don't think I can build either of the other approaches in the next week, but hopefully some time after that, depending on many other factors.

[syphar]

I think you're trying to fix two different problems here:

1. docs.rs issues

2. docs.rs changes

The first one needs to be there as long as the issue(s) are there. The second one being a notice, it should be discard-able by the user and attract attention a lot more. So your PR fits well for 1., but doesn't for 2. imo. 2. should most likely be a static element floating over the content.

What do you think?

Right now I don't have an opinion on that (too tired / sick), how does crates.io do it?

Generally what you propose feels like it makes sense.

[syphar]

general thought:

with my dayjob problems right now, I don't think I can spend time on any of the proposed other things in the next week or two (except when I'm lucky, not sure).

so I'm asking myself if we should use this first to make people aware of the new default-target change first?

[GuillaumeGomez]

I can take over this PR and implement the missing parts if you want?

[syphar]

I can take over this PR and implement the missing parts if you want?

thanks for the offer!

My hunch is that you're right generally, but I want to think it through first when I'm a little better.

[syphar]

( will set the compiled-in warning in a separate PR for the current change only)

[GuillaumeGomez]

Sounds good to me. :)

[syphar]

@GuillaumeGomez I had another idea about multiple alerts, the separate page looked so empty with the information that was there..

what do you think?

It would collapse (so no dropdown) when there is only one alert.

Also now there is an example how the webserver now collects metrics from the builder-lib.

( not sure if I was too much into it and overengineered 😅 )

[GuillaumeGomez]

Well, I was kinda hoping to provide more information for each anomaly on the page. 😆

Like since how long it's happening, what's the impact to users, etc.

[syphar]

Well, I was kinda hoping to provide more information for each anomaly on the page. 😆

Like since how long it's happening, what's the impact to users, etc.

Want to add a commit how you would imagine it?

[GuillaumeGomez]

I can try. :)

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[syphar]

I just rebased to fix the conflicts, will leave it alone now @GuillaumeGomez

[GuillaumeGomez]

I added the draft for the status page of docs.rs. It looks like this: