CSC/ECE 517 Fall 2024 - E2457. GitHub metrics integration

About Expertiza

Expertiza is a web-based, open-source educational platform built with Ruby on Rails by students and faculty at NC State University. It enables instructors to create flexible assignments that students can select based on their interests and supports team-based projects with a robust peer review system. Through peer evaluations, students gain critical feedback, enhancing self-improvement skills. With support for diverse submission types, Expertiza adapts easily to various assignment formats and teaching approaches.

Problem Statement

Expertiza currently has team reviews to measure how much each team member contributed to a project. However, it would be useful to instructors to be able to see github metrics on expertiza for each group to corroborate the team reviews. These metrics include number of commits, number of lines of code modified, number of lines added, and number of lines deleted.

Background

The main objective of the project is to refactor the code written by the Spring 2023 team for displaying github metrics. The main issue with this team's code is that metrics_controller.rb is too bloated as it has logic that should be in the model as well as having too many github specific methods. Since other metrics could be used in the future, a metrics_controller should be general. In addition, several method names are confusing and need to be renamed, and several methods adhere to the Single Responsibility Principle and so need to be split into multiple methods. Lastly, testing and comments on tests need to be improved.

For more information about the previous work done by the Spring 2023 team, visit their team wiki page here.

Changes to metrics_controller.rb

Renaming metrics_controller.rb to github_metrics_controller.rb

Firstly, metrics_controller will be renamed to github_metrics_controller to reflect its focus on GitHub-related functionality, as no other metrics are currently anticipated for this controller.

Moving Methods out of the Controller

The following functions do not belong in the controller and should live in either model or helper classes.

• github_metrics_for_submission: This method uses the session information to submit the github metrics. However, we can pass the session to the model to perform the same function.
• retrieve_github_data: This method takes a link and determines whether it's a link for a pull request or a repository link which determines how the metrics are returned. This should not be a controller method because the method is only concerned with how to handle the link submitted and not what to show the user.
• query_all_pull_requests: This method iterates over multiple pull request links and fetches the data from github. Because it is not concerned with what to show the user, it should live in the model.
• pull_request_data: This method iterates over pages of commits, preparing the metrics pulled from the commits for the parser. Since this is handling data collection, this method should be in the model.
• parse_pull_request_data: This method parses the metrics from the pull request and prepares it for the view. This means that it should be a model method instead of a controller method
• query_all_merge_statuses: This method iterates through all the pull request links and retrieves the status of each link. This is more data retrieval and so should be in a model instead of the controller
• retrieve_repository_data: This method fetches metrics from the github repository which means that it should be in a model instead of a controller method.
• parse_repository_data: This method parses the metrics retrieved from the repository and parses it for the view. This means that it should a model method instead of controller method
• count_github_authors_and_dates: This method processes the metrics from the commits and so should be a model method rather than a controller method.
• find_user_by_github_email: This method receives an email and then parses it to find a user. This is not a controller method because it is parsing data which means that it should either be in a model or service class. Moreover, this method has the false assumption that every email used will be an NC State email address, and so has to be reimplemented.

Renaming Methods

• retrieve_github_data: The name of this method is ambiguous because it is unclear what ‘data’ is. This method takes the links that a group submitted and determines whether it is a repository or pull request link and will then call the appropriate method to parse the metrics from the link. For this reason this method should be renamed to retrieve_github_metrics
• query_all_pull_requests: The name of this method is ambiguous as it is unclear what is being queried about for each pull request. This method iterates over all of the links and parses out the relevant information by getting the name of the owner from the hyperlink as well as retrieving the github metrics from the pull request. For this reason this method should be renamed parse_all_pull_requests
• pull_request_data: The name is ambiguous because it is unclear what ‘data’ is. This method retrieves the github metrics from the pull request link that it was passed. For this reason the method should be retrieve_pull_request_metrics
• parse_pull_request_data: The name is ambiguous because it is unclear what ‘data’ is. This method parses the metrics returned from the github API for the given pull request link. For this reason the method should be parse_pull_request_metrics
• retrieve_repository_data: The name is ambiguous because it is unclear what ‘data’ is. This method retrieves github metrics for the given github repository link. For this reason the name should be retrieve_repository_metrics
• parse_repository_data: The name is ambiguous because it is unclear what ‘data’ is. This method parses the metrics returned from the github API for the given repository link. For this reason the method should be parse_repository_metrics

Testing

To ensure the functionality and reliability of the GitHub metrics integration, we will conduct testing using RSpec and UI tests. This involves adding RSpec test commands for github_metric_controller and github_metric to verify that each component functions as expected within the refactored structure. Additionally, we will run UI tests to ensure that the GitHub metrics display accurately and integrate seamlessly within the Expertiza interface.

Team

Members

• Brandon Walia
• Kevin Dai
• Manav Patel

Mentor

• Dr. Ed Gehringer