ADR for Scorecard metrics aggregation and stack quality scoring #439
Conversation
sesheta
added
the
size/S
mayaCostantini
force-pushed
the
adr-scorecard-metrics
branch
from
334c2bf
to
1b1477d
Compare
|
|
||
| The data aggregation and score computation logic would be implemented as follows: | ||
|
|
||
| * With each `package-releases-job` run, aggregate data about the latest package release and corresponding Scorecards data retrieved from BigQuery |
There was a problem hiding this comment.
Can e use the scorecard command line Utility for this?
There was a problem hiding this comment.
As we want to aggregate data about packages we do not have yet into the prescriptions database, I don't think this will work unless we modify the scorecards handler logic. Another alternative to this architecture would be to compute prescriptions from new releases aggregated on package-release-job without storing this data in the DB, which will (if I'm not mistaken) greatly increase the number of prescriptions we already have. The global quality metrics could then be derived from prescriptions directly and stored in the DB on a regular job run for example.
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: goern The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
sesheta
added
the
approved
Related Issues and Dependencies
Related to #434 and thoth-station/thamos#1148
This introduces a breaking change
This Pull Request implements
ADR Proposal for aggregating OSSF Scorecards data and computing a software stack quality score.
The logic proposed below would imply to approximate properly the budget allocated to aggregate this data from BigQuery.
To estimate this budget, we would need information about the average number of packages updated with a new release on each
package-releases-jobrun and look more closely at BigQuery pricing according to the API calls we will need to make.