We are hoping to show that the cycle time between a Gerrit +2 and that changeset being active for testwiki users is much shorter than the current cycle time from Train deploys. To do that we need to track the data.
https://tools-static.wmflabs.org/train-stats/#lead-cycle-times
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Lferreira | T215217 deployment-prep (beta cluster): Code stewardship request | |||
| Open | Goal | None | T369112 Pretrain (née Group -1) QTE validation environment | ||
| Open | Feature | None | T420790 Collect data on merge to deploy cycle times for the rolling `wmf/next` branch so we can report on Pretrain impacts |
One thing we will need to be aware of in creating this data pipeline is that with the current implementation we will have wmf/next increments that are not deployed immediately. Specifically the branch cut job runs seven days a week, but the deploy job is currently planned to only run Monday-Thursday.
We are not producing any Changelog for wmf/next branches like the normal Train changelogs. We should, and when we do they should be based on the deployment increment, not the branch update frequency. This may be "interesting" to figure out, but ultimately there will be a treeish that is the deployed branch and it should be possible to produce various logs and diffs showing the incremental difference from the prior deployment. This whole topic may be more useful forked into another task to track design and implementation of such a system.