runbot/runbot_merge/changelog/2022-10/statuses.md

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.
[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-11-04 21:22:36 +07:00			`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.`