CSC/ECE 517 Fall 2024 - E2457. GitHub metrics

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.

Changes to metrics_controller.rb

Removing Github Specific Methods

The following functions are all github specific and should not live inside metrics_controller.rb. Instead they will be moved to github_metrics_controller.rb github_metrics_for_submission retrieve_github_data query_all_pull_requests pull_request_data parse_pull_request_data query_all_merge_statuses retrieve_repository_data parse_repository_data query_commit_statistics query_pull_request_status find_user_by_github_email authorize_github

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 updates, automated testing was implemented using GitHub Actions. All tests were executed with the command bundle exec rspec spec/, which allowed the full suite of tests to be ran, giving confirmation that the changes met the expected standards without introducing regressions.

Link to the changes here.

Team

Members

• Brandon Walia
• Kevin Dai
• Manav Patel

Mentor

• Dr. Ed Gehringer