-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[enriched] Add support for github pull request data #399
Conversation
This code proposes a possible implementation to include support for github pull request data in ELK.
This PR extends the mappings for the GitHub raw data to enable the support for pull request data,
@valeriocos I think this is much better than what I propose. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
If everybody agrees on this structure, @aswanipranjal could you modify your PR #398 according to what is proposed in this PR? |
Sorry for coming late to the discussion, but I agree with you all. What I don't understand is if you propose to substitute this pr with #398 (once modified), or to follow on until this one is merged. |
@valeriocos @jgbarah We should merge this PR and then I can create a commit to calculate the rich PR data |
sorry for not being clear @jgbarah . I agree with @aswanipranjal on merging this PR and then creating a new one with the rich PR data. |
@acs, please merge this PR? |
Done! Thanks for the heads up @aswanipranjal ! |
The main aim of this PR is to trigger the discussion about how to integrate GitHub pull request data in GrimoireLab. This PR proposes to extend GitHubOcean and GitHubEnrich to include the new data without creating a new connector. Conversely, PR #398 proposes to add a new connector to ELK.
This PR requires a modification to mordred (PR chaoss/grimoirelab-sirmordred#175) in order to allow the definition of multiple sections for the same backend (thus enabling the explotation of backends with multiple categories in a transparent way). On the other hand, PR #398 doesn't need to modify mordred, however it implies the creation of a dedicated connector for each category of a backend.
Given that both solutions have advantages and drawbacks, what are your thoughts @acs @jgbarah @aswanipranjal ?