Add SnapshotBuilder
Background
We generate various ResourceEvent
records whenever the following actions are taken:
- An issue is closed/reopened =>
ResourceStateEvent
- An issue is added to/removed from a timebox =>
ResourceMilestoneEvent
orResourceIterationEvent
- An issue is weighed =>
ResourceWeightEvent
- Issue and work items are linked =>
WorkItems::ResourceLinkEvent
Note that Issue
and Work Items
are using the same table. We plan to transition fully using Work Items down the road.
ResourceEvent
records can be used to generate historical snapshots of issues. Given an issue, if you are interested in finding out its state on some date, you simply have to query for all resource events leading up to that date:
- `Issue A` added to `Milestone A` on Apr 9 (`ResourceMilestoneEvent`)
- `Issue A` weighted at 2 on Apr 9 (`ResourceWeightEvent`)
- `Issue A` closed on Apr 10 (`ResourceStateEvent`)
- `Issue A` added to `Milestone B` on Apr 10 (`ResourceMilestoneEvent`)
- `Issue A` weighted at 5 on Apr 11 (`ResourceWeightEvent`)
- `Issue A` reopened on Apr 12 (`ResourceStateEvent`)
At the end of Apr 10, Issue A
had weight 2 and it had been closed. The issue had been part of Milestone A
.
At the end of Apr 12, Issue A
had weight 5 and it was reopened. The issue was part of Milestone B
.
In fact, when you visit the report page for a milestone or an iteration like this one https://gitlab.com/gitlab-org/gitlab/-/cadences/16671/iterations/106890, TimeboxReportService
computes the chart data using ResourceEvent
records.
Now TimeboxReportService
has grown into a complex class and I want to factor out one of its responsibilities into a new class called SnapshotBuilder
.
What does this MR do and why?
The newly added class SnapshotBuilder
will accept an ordered list of ResourceEvent
records and compute daily snapshots of issue states for either a milestone or an iteration. The ultimate goal is to refactor TimeboxReportService
to use SnapshotBuilder
in a later MR.
Related to #381879
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.