diff --git a/about.html b/about.html
index a544e58f31..4555d593c4 100644
--- a/about.html
+++ b/about.html
@@ -38,7 +38,7 @@
Committer [2018 Aug - 2018 Dec]
Contributor [2018 May - 2018 Aug]
Role: Maintainer [2020 May - 2021 Jan]
Project Lead [2018 May - 2020 May]
Contributor [2018 May - 2018 Aug]
Contributor [2018 Aug - 2019 May]
Contributor [2018 Dec - 2019 May]
Contributor [2018 Dec - 2019 May]
Contributor [2018 Dec - 2019 May]
Role: Contributor [2019 May - 2019 Aug]
Role: Committer [2020 May - 2021 Jan]
-Contributor [2019 May - 2020 May]
Role: Contributor [2019 May - 2020 May]
Role: Contributor [2020 January - 2020 May]
Role: Contributor [2020 January - 2020 May]
Role: Contributor [2020 January - 2020 May]
Role: Contributor [2019 August - 2021 May]
Role: Contributor [2019 August - 2021 August]
Role: Contributor [2019 September - 2020 August]
Role: Contributor [2020 January - 2021 May]
Role: Contributor [2021 January - 2021 March]
Role: Contributor [2019 May - 2020 May]
Role: Contributor [2020 January - 2020 May]
Role: Contributor [2020 January - 2020 May]
Role: Contributor [2020 January - 2020 May]
Role: Contributor [2019 August - 2021 May]
Role: Contributor [2019 August - 2021 August]
Role: Contributor [2019 September - 2020 August]
Role: Contributor [2020 January - 2021 May]
Role: Contributor [2021 January - 2021 March]
You can post your questions, suggestions, and bug reports in our issue tracker.
Alternatively, you can email us at seer@comp.nus.edu.sg
You can post your questions, suggestions, and bug reports in our issue tracker.
Alternatively, you can email us at seer@comp.nus.edu.sg
This page documents the various components that form part of the DevOps infrastructure that RepoSense uses.
GitHub Actions is a platform that is used by RepoSense for running the test suite and is primarily used for continuous integration and testing. The test suite is stored in .github/workflows/
and comprises of:
src/tests/
)src/systemtest/
)frontend/cypress/tests/
)All three types of tests in the test suite are run in a single GitHub Actions workflow called "Continuous Integration". The steps are defined in integration.yml
and are split into two types of jobs:
mainbuild
): Runs both unit tests and system tests on JDK 11 running on supported Ubuntu, macOS and Windows versions. For Ubuntu, this job also produces a RepoSense report and the MarkBind documentation website for previewing.cypress
): Runs only the frontend tests on JDK 11 running on Ubuntu.The list of supported OS versions are available on the GitHub Docs website. These jobs should be updated regularly whenever RepoSense supports newer versions of the Java Development Kit (JDK) as well as when new OS versions are made available (via the job OS matrix). Frontend tests are run separately to take advantage of parallel job execution.
Some of the jobs execute some commands that are too complicated to be included in the workflow configuration files. Such commands are written in the form of a bash script and are located in the config/gh-actions
folder.
This workflow is run for both incoming pull requests to any branch as well as direct commits to any branch in the repository.
Cypress frontend tests are run against reports generated from config files in frontend/cypress/config
. It uses the cypress
branch of the RepoSense repository which is kept independent of master
and should be updated only when there are new frontend tests that need to be accommodated.
For each pull request to any branch in the repository, a RepoSense report and the MarkBind documentation website is generated based on the code submitted in the pull request. This is to facilitate pull request reviewers in being able to quickly preview how the RepoSense report and/or the documentation website will change after the pull request is merged.
Due to security considerations in preventing pwn requests, the deployment of the report and documentation previews were split across two workflows in pull request #1411:
pending.yml
): Used for gathering information about the pull request and update the pull request checklist to indicate that the previews are pending.surge.yml
): Used for actually deploying the RepoSense report and documentation website to Surge.sh and updating the pull request checklist to link to the preview websites.The previews are recognised as GitHub deployments and are named dashboard-$PRNUMBER
and docs-$PRNUMBER
, where $PRNUMBER
is the pull request number. Once a preview is ready, the reviewer would be able to click on "View deployment" or "Show environments" in the pull request to open the preview websites.
Both the "Surge.sh pending build" and "Continuous Integration" workflows produce an artifact respectively, which is then downloaded by the "Surge.sh build preview" workflow to be deployed to Surge.sh. Due to limitations in GitHub Actions in determining the workflow execution order, the "Surge.sh pending build" workflow is assumed to have been completed before the "Continuous Integration" workflow is completed.
This task is not performed on commits to the repository, as there is no need to do so.
After the pull request is closed or merged, the Surge.sh deployments are retained, while the GitHub environments for them are cleared by another workflow "Clear deployments for closed pull requests" (defined in delete-deploy.yml
). The workflow uses delete-deploy.sh
(found in the config/gh-actions/
folder) to remove the environments on GitHub, and to leave a comment on the pull request with links to the Surge.sh previews for later reference.
This task builds the MarkBind documentation website on every push to the master
branch. The steps are defined in gh-pages.yml
.
This task automates the cleaning up of the pull requests by automatically marking inactive pull requests as stale and subsequently closing them. The steps and configurations are defined in stale.yml
and the job is triggered automatically once per day.
Codecov is a platform for checking the code coverage status of the project and the pull request patch. It runs automatically on each pull request and the settings are located in codecov.yml
.
Surge.sh is a platform for hosting the RepoSense report and documentation preview builds. The deployment is automatically performed by the "Surge.sh build preview" job using the deploy.sh
script in the config/gh-actions/
folder.
For authentication, two secrets are stored and used in GitHub Actions:
SURGE_LOGIN
- Holds the email address to use for the Surge.sh accountSURGE_TOKEN
- Holds the secret account token generated for the above account (generated using surge token
)The surge
command automatically detects the existence of these two environment variables and use them for authentication when deploying the RepoSense report and documentation build previews.
Currently, deployments are kept forever, even after the pull request is merged or closed. There is currently no existing functionality to automatically clean up deployments after they are no longer useful.
This page documents the various components that form part of the DevOps infrastructure that RepoSense uses.
GitHub Actions is a platform that is used by RepoSense for running the test suite and is primarily used for continuous integration and testing. The test suite is stored in .github/workflows/
and comprises of:
src/tests/
)src/systemtest/
)frontend/cypress/tests/
)All three types of tests in the test suite are run in a single GitHub Actions workflow called "Continuous Integration". The steps are defined in integration.yml
and are split into two types of jobs:
mainbuild
): Runs both unit tests and system tests on JDK 11 running on supported Ubuntu, macOS and Windows versions. For Ubuntu, this job also produces a RepoSense report and the MarkBind documentation website for previewing.cypress
): Runs only the frontend tests on JDK 11 running on Ubuntu.The list of supported OS versions are available on the GitHub Docs website. These jobs should be updated regularly whenever RepoSense supports newer versions of the Java Development Kit (JDK) as well as when new OS versions are made available (via the job OS matrix). Frontend tests are run separately to take advantage of parallel job execution.
Some of the jobs execute some commands that are too complicated to be included in the workflow configuration files. Such commands are written in the form of a bash script and are located in the config/gh-actions
folder.
This workflow is run for both incoming pull requests to any branch as well as direct commits to any branch in the repository.
Cypress frontend tests are run against reports generated from config files in frontend/cypress/config
. It uses the cypress
branch of the RepoSense repository which is kept independent of master
and should be updated only when there are new frontend tests that need to be accommodated.
For each pull request to any branch in the repository, a RepoSense report and the MarkBind documentation website is generated based on the code submitted in the pull request. This is to facilitate pull request reviewers in being able to quickly preview how the RepoSense report and/or the documentation website will change after the pull request is merged.
Due to security considerations in preventing pwn requests, the deployment of the report and documentation previews were split across two workflows in pull request #1411:
pending.yml
): Used for gathering information about the pull request and update the pull request checklist to indicate that the previews are pending.surge.yml
): Used for actually deploying the RepoSense report and documentation website to Surge.sh and updating the pull request checklist to link to the preview websites.The previews are recognised as GitHub deployments and are named dashboard-$PRNUMBER
and docs-$PRNUMBER
, where $PRNUMBER
is the pull request number. Once a preview is ready, the reviewer would be able to click on "View deployment" or "Show environments" in the pull request to open the preview websites.
Both the "Surge.sh pending build" and "Continuous Integration" workflows produce an artifact respectively, which is then downloaded by the "Surge.sh build preview" workflow to be deployed to Surge.sh. Due to limitations in GitHub Actions in determining the workflow execution order, the "Surge.sh pending build" workflow is assumed to have been completed before the "Continuous Integration" workflow is completed.
This task is not performed on commits to the repository, as there is no need to do so.
After the pull request is closed or merged, the Surge.sh deployments are retained, while the GitHub environments for them are cleared by another workflow "Clear deployments for closed pull requests" (defined in delete-deploy.yml
). The workflow uses delete-deploy.sh
(found in the config/gh-actions/
folder) to remove the environments on GitHub, and to leave a comment on the pull request with links to the Surge.sh previews for later reference.
This task builds the MarkBind documentation website on every push to the master
branch. The steps are defined in gh-pages.yml
.
This task automates the cleaning up of the pull requests by automatically marking inactive pull requests as stale and subsequently closing them. The steps and configurations are defined in stale.yml
and the job is triggered automatically once per day.
Codecov is a platform for checking the code coverage status of the project and the pull request patch. It runs automatically on each pull request and the settings are located in codecov.yml
.
Surge.sh is a platform for hosting the RepoSense report and documentation preview builds. The deployment is automatically performed by the "Surge.sh build preview" job using the deploy.sh
script in the config/gh-actions/
folder.
For authentication, two secrets are stored and used in GitHub Actions:
SURGE_LOGIN
- Holds the email address to use for the Surge.sh accountSURGE_TOKEN
- Holds the secret account token generated for the above account (generated using surge token
)The surge
command automatically detects the existence of these two environment variables and use them for authentication when deploying the RepoSense report and documentation build previews.
Currently, deployments are kept forever, even after the pull request is merged or closed. There is currently no existing functionality to automatically clean up deployments after they are no longer useful.
Thank you for your interest in contributing to RepoSense! We welcome PRs, especially from students.
Here is a quick overview of how to get started.
To gain a more solid understanding of the project implementation and workflow, you may want to start by working on issues that are suitable for first timers.
We look forward to your PR. Happy coding!
Thank you for your interest in contributing to RepoSense! We welcome PRs, especially from students.
Here is a quick overview of how to get started.
To gain a more solid understanding of the project implementation and workflow, you may want to start by working on issues that are suitable for first timers.
We look forward to your PR. Happy coding!
Prerequisites:
JDK 11.0.21+9
up to 17
(download ).
Node.js 18
up to the latest minor version of 19
(download ).
Git 2.23
or later (download ).
Type java -version
, node -v
and git --version
respectively on your OS terminal and ensure that you have the correct version of each prerequisite installed.
The recommended IDE is Intellij IDEA. While it is not compulsory to use it, note that we will not be able to help you troubleshoot IDE problems if you use any other IDE.
This project is already configured to use Gradle for build automation. If you are new to Gradle, see this tutorial to learn how to use it.
gradlew clean build
(./gradlew clean build
if you on a Unix-like OS), and ensure that it finishes with a BUILD SUCCESSFUL
message.gradlew test systemtest
command and ensure it succeeds too.... read the Workflow section.
Prerequisites:
JDK 11.0.21+9
up to 17
(download ).
Node.js 18
up to the latest minor version of 19
(download ).
Git 2.23
or later (download ).
Type java -version
, node -v
and git --version
respectively on your OS terminal and ensure that you have the correct version of each prerequisite installed.
The recommended IDE is Intellij IDEA. While it is not compulsory to use it, note that we will not be able to help you troubleshoot IDE problems if you use any other IDE.
This project is already configured to use Gradle for build automation. If you are new to Gradle, see this tutorial to learn how to use it.
gradlew clean build
(./gradlew clean build
if you on a Unix-like OS), and ensure that it finishes with a BUILD SUCCESSFUL
message.gradlew test systemtest
command and ensure it succeeds too.... read the Workflow section.
Scenario: RepoSense is used to monitor a Software Engineering course in which students build a project over 8 weeks.
Links: report | repo containing the settings
Example usages:
Scenario: Similar to case 1 above, but this time students are doing team projects.
Example usages:
breakdown by file type
checkbox, as shown in this view. After that, we can filter out certain file types by un-ticking the file type.merge all groups
check-box and sort groups by Contribution
, as seen in this view. Also, note how to reduce clutter.Scenario: Similar to cases 1 and 2 above, but this time, each student works on multiple projects. Furthermore, most projects are external OSS projects, not within the control of the teacher.
Example usages:
group by
drop-down to organize activities around projects or individual authors.merge all groups
check-box to see the sum of activities in a specific project or by a specific student.Scenario: RepoSense is used to monitor a Software Engineering course in which students build a project over 8 weeks.
Links: report | repo containing the settings
Example usages:
Scenario: Similar to case 1 above, but this time students are doing team projects.
Example usages:
breakdown by file type
checkbox, as shown in this view. After that, we can filter out certain file types by un-ticking the file type.merge all groups
check-box and sort groups by Contribution
, as seen in this view. Also, note how to reduce clutter.Scenario: Similar to cases 1 and 2 above, but this time, each student works on multiple projects. Furthermore, most projects are external OSS projects, not within the control of the teacher.
Example usages:
group by
drop-down to organize activities around projects or individual authors.merge all groups
check-box to see the sum of activities in a specific project or by a specific student.You are looking at the user documentation for the most recent master
branch of RepoSense (not released to the public yet). The documentation for the latest public release is here.
author-config.csv
advanced syntaxGiven below are the advanced syntax available for author-config.csv
.
Repository's Location
per authorRepository's Location
To specify multiple Repository's Location
in a single row, we can use a semicolon ;
as a separator.
Below is an example:
Repository's Location | Branch | Author's Git Host ID | ... Hidden columns |
---|---|---|---|
https://github.com/reposense/RepoSense.git;https://github.com/MarkBind/markbind.git | master | sikai00 | -- |
We have now furnished author details for both repositories in a single row, instead of having two individual rows per Repository's Location
.
Repository's Location
with one or more specific branchesTo list out one or more branches for a particular Repository's Location
, we can use a pipe |
separator to demarcate the different branches.
Below is an example:
Repository's Location | Branch | Author's Git Host ID | ... Hidden columns |
---|---|---|---|
https://github.com/reposense/RepoSense.git~master|release|cypress | master | sikai00 | -- |
We have now provided author details for three different branches in a single repo, using a single row.
The branch specified through the delimiter syntax will take precedence over the Branch
column.
Repository's Location
We can also use GitHub branch URL as copied from the address bar directly, to be able to quickly use the URL to specify the Repository's Location
and a specific Branch
at the same time.
Below is an example:
Repository's Location | Branch | Author's Git Host ID | ... Hidden columns |
---|---|---|---|
https://github.com/reposense/RepoSense/tree/release | sikai00 | -- |
There is no need to specify the Branch
column now, as we have specified it through the GitHub branch URL.
GitLab and BitBucket branch URL are not supported at the moment.
It is possible to combine the above-mentioned advanced syntax. By doing so, we can go from:
Repository's Location | Branch | Author's Git Host ID | ... Hidden columns |
---|---|---|---|
https://github.com/MarkBind/markbind/tree/vue3-migration | sikai00 | -- | |
https://github.com/reposense/RepoSense.git | master | sikai00 | -- |
https://github.com/reposense/RepoSense.git | cypress | sikai00 | -- |
to:
Repository's Location | Branch | Author's Git Host ID | ... Hidden columns |
---|---|---|---|
https://github.com/MarkBind/markbind/tree/vue3-migration;https://github.com/reposense/RepoSense.git~master|cypress | sikai00 | -- |
You are looking at the user documentation for the most recent master
branch of RepoSense (not released to the public yet). The documentation for the latest public release is here.
author-config.csv
advanced syntaxGiven below are the advanced syntax available for author-config.csv
.
Repository's Location
per authorRepository's Location
To specify multiple Repository's Location
in a single row, we can use a semicolon ;
as a separator.
Below is an example:
Repository's Location | Branch | Author's Git Host ID | ... Hidden columns |
---|---|---|---|
https://github.com/reposense/RepoSense.git;https://github.com/MarkBind/markbind.git | master | sikai00 | -- |
We have now furnished author details for both repositories in a single row, instead of having two individual rows per Repository's Location
.
Repository's Location
with one or more specific branchesTo list out one or more branches for a particular Repository's Location
, we can use a pipe |
separator to demarcate the different branches.
Below is an example:
Repository's Location | Branch | Author's Git Host ID | ... Hidden columns |
---|---|---|---|
https://github.com/reposense/RepoSense.git~master|release|cypress | master | sikai00 | -- |
We have now provided author details for three different branches in a single repo, using a single row.
The branch specified through the delimiter syntax will take precedence over the Branch
column.
Repository's Location
We can also use GitHub branch URL as copied from the address bar directly, to be able to quickly use the URL to specify the Repository's Location
and a specific Branch
at the same time.
Below is an example:
Repository's Location | Branch | Author's Git Host ID | ... Hidden columns |
---|---|---|---|
https://github.com/reposense/RepoSense/tree/release | sikai00 | -- |
There is no need to specify the Branch
column now, as we have specified it through the GitHub branch URL.
GitLab and BitBucket branch URL are not supported at the moment.
It is possible to combine the above-mentioned advanced syntax. By doing so, we can go from:
Repository's Location | Branch | Author's Git Host ID | ... Hidden columns |
---|---|---|---|
https://github.com/MarkBind/markbind/tree/vue3-migration | sikai00 | -- | |
https://github.com/reposense/RepoSense.git | master | sikai00 | -- |
https://github.com/reposense/RepoSense.git | cypress | sikai00 | -- |
to:
Repository's Location | Branch | Author's Git Host ID | ... Hidden columns |
---|---|---|---|
https://github.com/MarkBind/markbind/tree/vue3-migration;https://github.com/reposense/RepoSense.git~master|cypress | sikai00 | -- |
You are looking at the user documentation for the most recent master
branch of RepoSense (not released to the public yet). The documentation for the latest public release is here.
Welcome to the RepoSense user guide. This user guide takes you through a three-step approach to adopting RepoSense for your own use.
In case you missed it, the overview of RepoSense is given below.
Report: We use the term report to refer to the web-based visualization generated by RepoSense. You can also think of it as a dashboard.
If still not entirely sure if RepoSense matches your needs, you can use the examples of real-life RepoSense reports given below to get some sense of what visualizations it produces.
As you explore the above examples, you can refer to the following section to learn how to read and interact with those reports.
The next step is to generate your own RepoSense reports, either in your computer, or on one of the remote platforms we support.
As you generate reports, you may need to learn how to customize those reports further.
Finally, you can learn how to share those reports with others, and how to automate the whole process.
If you encounter problems at any step, you can refer to our FAQ, the troubleshooting guide, or post in our issue tracker.
You are looking at the user documentation for the most recent master
branch of RepoSense (not released to the public yet). The documentation for the latest public release is here.
Welcome to the RepoSense user guide. This user guide takes you through a three-step approach to adopting RepoSense for your own use.
In case you missed it, the overview of RepoSense is given below.
Report: We use the term report to refer to the web-based visualization generated by RepoSense. You can also think of it as a dashboard.
If still not entirely sure if RepoSense matches your needs, you can use the examples of real-life RepoSense reports given below to get some sense of what visualizations it produces.
As you explore the above examples, you can refer to the following section to learn how to read and interact with those reports.
The next step is to generate your own RepoSense reports, either in your computer, or on one of the remote platforms we support.
As you generate reports, you may need to learn how to customize those reports further.
Finally, you can learn how to share those reports with others, and how to automate the whole process.
If you encounter problems at any step, you can refer to our FAQ, the troubleshooting guide, or post in our issue tracker.
You are looking at the user documentation for the most recent master
branch of RepoSense (not released to the public yet). The documentation for the latest public release is here.
run.sh
is a script used for automating RepoSense report generation.
You can update the RepoSense command (i.e., the last line) in the run.sh
to match your needs.
Depending on which version you wish to use for report generation, add one of the following flags to the line ./get-reposense.py
in run.sh
(e.g., ./get-reposense.py --release
):
--release
: Use the latest release (Stable)--master
: Use the latest version of the master branch--tag TAG
(e.g. --tag v1.6.1
): Use the version identified by the Git tag given--commit COMMIT
(e.g. --commit abc123
): Use the version identified by the Git commit SHA givenYou are looking at the user documentation for the most recent master
branch of RepoSense (not released to the public yet). The documentation for the latest public release is here.
run.sh
is a script used for automating RepoSense report generation.
You can update the RepoSense command (i.e., the last line) in the run.sh
to match your needs.
Depending on which version you wish to use for report generation, add one of the following flags to the line ./get-reposense.py
in run.sh
(e.g., ./get-reposense.py --release
):
--release
: Use the latest release (Stable)--master
: Use the latest version of the master branch--tag TAG
(e.g. --tag v1.6.1
): Use the version identified by the Git tag given--commit COMMIT
(e.g. --commit abc123
): Use the version identified by the Git commit SHA givenYou are looking at the user documentation for the most recent master
branch of RepoSense (not released to the public yet). The documentation for the latest public release is here.
RepoSense is a powerful tool for analyzing repositories. It provides valuable insights into your codebase, helping you understand the development patterns, identify areas for improvement, and track the contributions of individual team members.
You are looking at the user documentation for the most recent master
branch of RepoSense (not released to the public yet). The documentation for the latest public release is here.
RepoSense is a powerful tool for analyzing repositories. It provides valuable insights into your codebase, helping you understand the development patterns, identify areas for improvement, and track the contributions of individual team members.