2016-03-08 16:50:43 +01:00
|
|
|
<?php
|
|
|
|
|
|
|
|
final class NuanceGitHubRepositorySourceDefinition
|
|
|
|
extends NuanceSourceDefinition {
|
|
|
|
|
|
|
|
public function getName() {
|
|
|
|
return pht('GitHub Repository');
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getSourceDescription() {
|
|
|
|
return pht('Import issues and pull requests from a GitHub repository.');
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getSourceTypeConstant() {
|
|
|
|
return 'github.repository';
|
|
|
|
}
|
|
|
|
|
|
|
|
public function hasImportCursors() {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
protected function newImportCursors() {
|
|
|
|
return array(
|
|
|
|
id(new NuanceGitHubRepositoryImportCursor())
|
|
|
|
->setCursorKey('events.repository'),
|
Split the GitHub import cursor into separate repository and issues event importers
Summary:
Ref T10538. The primary GitHub event activity stream does not report minor events (labels, milestones, etc).
GitHub has a second, similar activity stream which does report these events (the "Issues Events API").
Use two separate cursors: one consumes the primary stream; the second consumes the events stream.
One possible issue with this is that we may write events in a different order than they occurred, so GitHub shows "comment, label, close" but we show "comment, close, label" or similar. This is probably OK because the secondary API doesn't seem to have any very important events (e.g., it's probably fine if label changes are out-of-order), but we can conceivably put some buffer stage in between the two if it's an issue.
Test Plan: {F1164894}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10538
Differential Revision: https://secure.phabricator.com/D15446
2016-03-09 14:35:08 +01:00
|
|
|
id(new NuanceGitHubIssuesImportCursor())
|
|
|
|
->setCursorKey('events.issues'),
|
2016-03-08 16:50:43 +01:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|