Skip to content

a8n: Implement GraphQL API for Burndown Chart

Warren Gifford requested to merge a8n/burndown-chart into master

Created by: mrnugget

IMPORTANT: This branch is rebased onto #5913 to use a few changes of it. Once #5913 is merged, I'll change the base of this PR to master.

This PR adds the proposed ChangesetCountsOverTime query to the GraphQL API: https://github.com/sourcegraph/sourcegraph/pull/5847

How it does that is relatively easy to explain on a high level:

  • In the CampaignResolver's ChangesetCountsOverTime method we first load all Changesets belonging to that campaign and then all ChangesetEvents belonging to that campaign (through the changeset IDs) (right now this is done with a sub-query but could also be changed to use the changeset IDs as input)
  • Then we pass the input parameters from and to, two timestamps, with the changesets and the events to a8n.CalcCounts.
  • a8n.CalcCounts then generates as many *a8n.ChangesetCounts as 24-hour-intervals fit between from and to, starting to go back from to.
  • After sorting the events based on their timestamp and mapping them to their changesets, it tries to reconstructs each changesets state for each desired "point in time".

The majority of the logic here then happens in a8n.CalcCounts. Take a look at enterprise/pkg/a8n/counts.go and the test file enterprise/pkg/a8n/counts_test.go

There are loops in loops, yes, we record the state of a single Changeset for a given point in time by replaying the events up until that point. An optimization could be to only "unroll" the events only once and record the complete state every time it changes in a separate state machine and then we could potentially ask "what was this changesets state at this point in time?"

But that's a second step ("make it work, make it fast") that I possibly want to attempt once this is merged and if that optimization is even possible.

What's missing:

  • No Bitbucket Server support yet (we need to record the BBS events first)

Merge request reports