mirror of
https://github.com/odoo/runbot.git
synced 2025-03-19 17:35:45 +07:00
1c76a675c2
If a PR is cancel=staging, even if it's not the urgentest (priority=alone) odds are good it's being staged to fix the split. And even if it's not, it probably can't hurt. So cancel splits in order to stage it. This may be slightly harmful if the split is legit and has nothing to do with the PR being prioritised, but that seems like the less likely scenario. And having to update staging priorities on the fly seems like a bad idea. Though obviously it might do nothing if the PRs are in "default" priority.# Also simplify the unstage trigger from the PRs becoming ready: - the user is useless as it's always the system user - the batch id is not really helpful |
||
|---|---|---|
| .. | ||
| crons | ||
| project_freeze | ||
| staging_cancel | ||
| __init__.py | ||
| batch.py | ||
| commands.py | ||
| events_sources.py | ||
| ir_actions.py | ||
| project.py | ||
| pull_requests.py | ||
| res_partner.py | ||
| stagings_create.py | ||
| utils.py | ||