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
..
branch.md	[REV] runbot_merge: don't close PRs when deactivating branches	2022-12-01 10:57:32 +01:00
labels.md	[FIX] runbot_merge: make timestamps and batch labels selectable	2022-12-01 10:57:32 +01:00
squash.md	[ADD] runbot_merge: multi-commit squash mode	2022-12-01 10:57:32 +01:00
statuses.md	[FIX] runbot_merge: lock-in statuses after a staging has finished	2022-12-01 10:57:32 +01:00