build queue: refactor & cache priority-finding for new releases - #3378
Conversation
f519c43 to
54fbb41
Compare
15607ca to
96f788a
Compare
This comment has been minimized.
This comment has been minimized.
96f788a to
d33a1e7
Compare
d33a1e7 to
b941287
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
b941287 to
8d8459b
Compare
This comment has been minimized.
This comment has been minimized.
c07ade6 to
4dbaa2b
Compare
This comment has been minimized.
This comment has been minimized.
65e13ed to
c3393a1
Compare
This comment has been minimized.
This comment has been minimized.
|
Can you not include |
this will only work after merge, so CI on the PR will always be red? or am I missing something? |
|
but a valid point, let me think about a good solution. I could imagine one when we have the new infra, not sure with the current infra. |
|
Isn't the CI regenerate them? Because I don't commit my sqlx changes anymore as they never work for some reason. ^^' |
|
Hum, maybe we should do that. Would simplify things a lot. |
|
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. |
62d5415 to
28856cb
Compare
|
@GuillaumeGomez I rebased on |
|
Looks good to me! |
prep-work for the SQS ingestion from crates.io so we support a higher load in event ingestion without all these queries.
reevaluate_priorities) every now and then, which would update priorities of already queued releases, if the underlying data changes (patterns, workspace sizes, ...), but that's more optional.FakeGithubStatsstruct and improved some code quality in tests.