Xavier Morel f367a64481 [IMP] *: trigger-ify merge cron ... The merge cron is the one in charge of checking staging state and either integrating the staging into the reference branch (if successful) or cancelling the staging (if failed). The most obvious trigger for the merge cron is a change in staging state from the states computation (transition from pending to either success or failure). Explicitly cancelling / failing a staging marks it as inactive so the merge cron isn't actually needed. However an other major trigger is *timeout*, which doesn't have a trivial signal. Instead, it needs to be hooked on the `timeout_limit`, and has to be re-triggered at every update to the `timeout_limit`, which in normal operations is mostly from "pending" statuses bumping the timeout limit. In that case, `_trigger` to the `timeout_limit` as that's where / when we expect a status change. Worst case scenario with this is we have parasitic wakeups of this cron, but having half a dozen wakeups unnecessary wakeups in an hour is still probably better than having a wakeup every minute.		2024-08-02 15:14:50 +02:00
..
merge_cron.xml	[IMP] *: trigger-ify merge cron	2024-08-02 15:14:50 +02:00
runbot_merge.pull_requests.feedback.template.csv	[CHG] forwardport: notify the outstanding forwardports rather than source	2024-06-04 08:56:51 +02:00