The CI pipelines minutes usage as reported on the Usage Quotas page only shows the current month usage which is reset every month and there is no way to view activity in past months for analyzing historical usage by monthly and by the project. Now there are two charts that enable users to view their historical usage of CI pipeline minutes for shared runners to make informed decisions.
Problem to solve
The CI minutes usage as reported on the Usage Quotas page only shows current month usage which is reset every month and there is no way to view activity in past months for analyzing historical usage by monthly and by project.
As a user whose project consumes CI minutes, I want to see historical usage data so that I can anticipate usage in the current month based past months' activity.
@thaoyeager planning ended for 13.5 yesterday so it's probably too late to have something still in design that's a candidate. Can you please take a look?
I don't think we currently store historical data. We only store a running sum of minutes used in the current month. We'll have to create a data structure to store historical data. I'm not sure if we already have a re-usable component in the codebase that we can leverage. I think this might be something we should deliver in two iterations (first to create the data structure to store historical data, and the second to surface that to the user).
As for the frontend part, we already have the chart component that can renders area charts together ( I actually worked on the code coverage chart for testing which was very similar). The data structure that we expect is an array of objects/hashes where we have a name (in this case, it would be the project name) and then the data for that category in an array where each entry contains the x and y axis values.
I don't think we currently store historical data. We only store a running sum of minutes used in the current month.
@matteeyah There is a chance some data is being stored; I'm working to track down the data source of the blog statement "We evaluated CI/CD minute usage and found that 98.5% of free users use 400 CI/CD minutes or less per month."
We'll have to create a data structure to store historical data... I think this might be something we should deliver in two iterations (first to create the data structure to store historical data, and the second to surface that to the user).
Is it possible to do this as a separate MR in this issue, as in separate from the MR for frontend UI work? I'd like to avoid separate issues for BE and FE work.
@thaoyeager That depends on which graph we are making. Do we do only the conglomeration of minutes per month, or do we only do the minutes per month per project? Or both? 🤔
Is it possible to do this as a separate MR in this issue, as in separate from the MR for frontend UI work? I'd like to avoid separate issues for BE and FE work.
The two iterations are not to split the backend and frontend work. If we change the place how we store this data, we're going to have to run a database migration to migrate the old data and change the background workers for resetting the counters. It's easier to maintain data integrity if this is stretched over multiple iterations.
@matteeyah There is a chance some data is being stored; I'm working to track down the data source of the blog statement "We evaluated CI/CD minute usage and found that 98.5% of free users use 400 CI/CD minutes or less per month."
This might be stored in our data warehouse (Periscope or Snowplow), not sure if that's where that data is coming from.
Do we do only the conglomeration of minutes per month, or do we only do the minutes per month per project? Or both?
@f_caplette Ultimately we want to have both, but if that is a large effort for one issue, then first iteration would be all CI minutes per month and second iteration give a breakdown by project within a given month.
@matteeyah Thanks for the explanation on the two iteration. As discussed at weekly sync today, I'm moving this to %13.6 to allow time in current milestone to figure out the data structure, adjust design and figure out the scope of first iteration.
@samdbeckham Still waiting to make sure this comment is addressed: #246844 (comment 413104728) as the mockups were showing 2 type of data shown, but it seems we are okay with just one at the moment.
If we just want to show data for each project per month, then this is a 3 for the FE and it's ready. If we want to show 2 different graphs, then it's probably closer to 5 and needs more clarification before moving.
@samdbeckham Done; and as discussed at weekly sync today, I moved this issue to %13.6 to allow time in current milestone to figure out the data structure, adjust design and figure out the scope of first iteration.
I've added the larger of the weights mentioned by @f_caplette and added @matteeyah's weight of 4 as well. We can certainly reinspect this during planning of %13.6 to see how we can break this down further.
I'm actually going to remove the number assigned to the Weight field for now.
I'm going to unassign myself since I'm not actively working on this - we still need to figure out a couple of things about the implementation. I already have a big (weight 4) issue that I'm working on in this milestone, so even if we figured all of the uncertainties out in the next day or so, I couldn't commit to delivering this in %13.5.
@thaoyeager This seems like a joint effort to get this ~"candidate::13.6" issue refined and weighted.
@matteeyah and @pburdette - can I ask you two to collaborate on this one, especially if the given weights are currently quite large, is there a first iteration we can make to get some of this done?
I broke off a backend issue that I think would be a good first iteration towards this. It's about simply persisting historical data in the database for each project - #260872 (closed)
Users won't be able to notice anything after the first iteration, as it's a completely ~backstage change.
A second step would be to surface this to the frontend in aggregate format. This is where we can create a chart that shows this information.
The description here matches the first user-visible iteration we're going to make. #260872 (closed) is ~backstage grunt work that needs to happen before we can start working on this.
@cheryl.li my recommendation wouldn't be to rewrite this one to be the first non-customer facing step, and then make a new issue that's a copy of this on, but to keep the two issues you have. Both look like they are being considered for 13.6 and this is marked as blocked by that one, so maybe it's already ok?
As far as weights, each issue should have its own independent and accurate weight rather than summing them together and copying that sum value to both.
All in all it sounds like what @matteeyah is proposing above would be my recommendation too.