Subtask of #79550: Automate gathering of quality metrics and Project metrics for drupal.org redesign:

I think it's safe to assume that the callbacks to generate various metrics are going to potentially be pretty expensive to run. We're not going to want to trigger all of this directly in hook_cron(). Instead, project_metrics should ship with a drush command. It's up to you to trigger this command periodically (e.g. via UNIX cron, hudson, whatever). The drush command should do the following:

- Invoke the info hook (see #889888: Design, document and invoke an info hook for modules to advertise metrics they support) to get info about all the available metrics (actually, it'd call project_metrics_load_info() or whatever, but you get the idea).

- For each metric, figure out the last timestamp it has data for. If it's time to compute again, invoke the right metrics callback and store the results. (Who does the iterating over the projects depends on how the callbacks are going to work over at #889888)...

...

We should probably design this drush command so it takes a command-line arg to limit it to only operate on a single metric (module, delta) so that you don't necessarily have to run all of it at once, but could stagger the processing on different metrics if you need to.

Comments

hunmonk’s picture

hunmonk commented

We should probably design this drush command so it takes a command-line arg to limit it to only operate on a single metric (module, delta) so that you don't necessarily have to run all of it at once, but could stagger the processing on different metrics if you need to.

i'd say two optional args: drush process-project-metrics [module] [delta] -- then, no args gives you all metrics, one arg gives you all metrics for one module, and two args gives you one metric.

i'm also wondering if we'd want switches to specify the time range (in case we need to reprocess a period because of a bug, for example).

dww’s picture

dww
we/he/they
commented

and also an optional arg to only compute metrics for a single project, just like we have such an arg for the packaging script and the release history generation scripts. if nothing else, useful for debugging/development. but also potentially useful down the road...

hunmonk’s picture

hunmonk commented
Project: Project » Drupal.org Redesign
Version: 6.x-1.x-dev »
Component: Metrics » Everything Else
Issue tags: -project metrics +metrics

no official project exists for this module yet. moving to redesign queue for now, and retagging

hunmonk’s picture

hunmonk commented
Title: Create a drush command to trigger metrics computation and store results » Create a drush plugin to drive metrics processing
Assigned: Unassigned » hunmonk
hunmonk’s picture

hunmonk commented
Project: Drupal.org Redesign » Sampler API
Version: » 6.x-1.x-dev
Component: Everything Else » Code

moving this issue to the new module's home...

hunmonk’s picture

hunmonk commented
Status: Active » Fixed

done and committed. includes support for:

  1. listing all plugin types/handlers
  2. listing all metrics
  3. running sampling for individual metrics, all metrics a module provides, and all metrics -- options that can be passed to the handlers can be passed on the drush command line, too.
  4. updating the storage handler for a metric
  5. deleting all data and schema state information for a metric

Status: Fixed » Closed (fixed)
Issue tags: -drupal.org redesign, -drupal.org redesign project, -drupal.org redesign sprint 3, -metrics

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue tags: +drupal.org redesign, +drupal.org redesign project, +drupal.org redesign sprint 3, +metrics

Restoring issue tags, see #2125755: System messages removed all issue tags during D7 upgrade.