[CI] Remove need for operational metrics persistent storage

[jriv01]

Originally, the script for scraping LLVM commit info required persistent storage to keep track of the last commit we've seen. This was to prevent any overlap in our scrapes and avoid processing the same commits multiple times.

However, currently the script will only ever scrape a full day at a time, so there should never be any overlap. We no longer need persistent storage to maintain the most recently viewed commits since we don't expect the CronJob to be executed twice in the same day.

[jriv01]

@boomanaiden154

[boomanaiden154]

The changes look reasonable enough to me.

I'm not super confident in the read_past_commits implementation though. The commit date I'm assuming is the date set by the commit when you run git commit or when you manually override the date. I don't think that would work for this kind of query.

But it seems like you have done some testing and this works as expected?

[jriv01]

The changes look reasonable enough to me.

I'm not super confident in the read_past_commits implementation though. The commit date I'm assuming is the date set by the commit when you run git commit or when you manually override the date. I don't think that would work for this kind of query.

But it seems like you have done some testing and this works as expected?

Thanks for pointing that out, after looking into it seems like this is the date git commit was ran or when the commit was merged/rebased.

We might miss some commits when the commit date is set to a date the CronJob has already scraped, but I think that's okay for the purposes of this dashboard. From a quick check of recent history (since 01-01-2022), only about 1.4% of commits aren't chronologically consistent with their position in the branch's history.

To get the amount of pushes made on a particular day, we'd probably have to use the GitHub Events API which is something we want to lean away from.