You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When testing a regressed rollup, we may want to enqueue more than one build at a time. However, this is not possible because of a constraint on the database (found here). It's not clear to me if this constraint is actually needed or not. I can see how it might prevent certain bugs where we overly commit try builds, but in this case it is too restrictive. Can we remove this constraint?
The text was updated successfully, but these errors were encountered:
I believe the goal with the constraint was to deduplicate queueing, to make rust-timer queue essentially idempotent. I don't think it needs to be the case when directly specifying a SHA to build via rust-timer build, though.
I'd need to put some thought into quite how we manage that from a DB perspective, but it's also plausible we could just drop the constraint entirely. I think it was mostly intended to prevent needing to decide which row to attach to when we have a build ready to start...
When testing a regressed rollup, we may want to enqueue more than one build at a time. However, this is not possible because of a constraint on the database (found here). It's not clear to me if this constraint is actually needed or not. I can see how it might prevent certain bugs where we overly commit try builds, but in this case it is too restrictive. Can we remove this constraint?
The text was updated successfully, but these errors were encountered: