NextERP/runbot
5
0
Fork 0
mirror of https://github.com/odoo/runbot.git synced 2025-03-15 23:45:44 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
18.0
runbot/runbot_merge/changelog/2022-10/statuses.md
Xavier Morel 985aaa5798 [FIX] runbot_merge: lock-in statuses after a staging has finished 
The `statuses` field of a staging is always "live" because it's a
computed non-stored field. This is an issue when a staging finishes in
whatever state, then someone gets new statuses sent on one of the head
commits, either by rebuilding (part of) the staging or by just using
the same commit for one of their branches.

This makes the reporting of the main dashboard confusing, as one might
look at a failed staging and see all the required statuses
successful. It also makes post-mortem analysis more complicated as the
logs have to be trawled for what the statuses used to be (and they
don't always tell).

Solve this by storing a snapshot of the statuses the first time a
staging moves away from `pending`, whether it's to success or failure.

Fixes #667
2022-12-01 10:57:32 +01:00

525 B
Raw Permalink Blame History

FIX: lock in statuses at the end of a staging

The statuses of a staging are computed dynamically. Because github associates statuses with commits, rebuilding a staging (partially or completely) or using one of its commits for a branch could lead to the statuses becoming inconsistent with the staging e.g. all-green statuses while the staging had failed.

By locking in the status at the end of the staging, the dashboard is less confusing and more consistent, and post-mortem analysis (e.g. of staging failures) easier.