mirror of
https://github.com/odoo/runbot.git
synced 2025-03-19 17:35:45 +07:00
e6057afde7
Commits can take some time to propagate through the network (I guess), or human error can lead to the wrong commit being set. Either way, because the entire thing was done using a single fetch in `check=True` the cron job would fail entirely if any of the patch commits was yet unavailable. Update the updater to: - fallback on individual fetches - remove the patch from the set of applicable patch if we (still) can't find its commit I'd have hoped `fetch` could retrieve whatever it found, but apparently the server just crashes out when it doesn't find the commit we ask for, and `fetch` doesn't update anything. No linked issue because I apparently forgot to jot it down (and only remembered about this issue with the #1063 patching issue) but this was reported by mat last week (2025-02-21) when they were wondering why one of their patches was taking a while: - At 0832 patch was created by automated script. - At 0947, an attempt to apply was made, the commit was not found. - At 1126, a second attempt was made but an other patch had been created whose commit was not found, failing both. - At 1255, there was a concurrency error ("cannot lock ref" on the target branch). - Finally at 1427 the patch was applied. All in all it took 6 hours to apply the patch, which is 3-4 staging cycles. |
||
|---|---|---|
| .. | ||
| backport | ||
| crons | ||
| ir_cron | ||
| project_freeze | ||
| staging_cancel | ||
| __init__.py | ||
| batch.py | ||
| commands.py | ||
| events_sources.py | ||
| ir_actions.py | ||
| ir_ui_view.py | ||
| mail_thread.py | ||
| patcher.py | ||
| project.py | ||
| pull_requests.py | ||
| res_partner.py | ||
| stagings_create.py | ||
| utils.py | ||