Workflow

To submit a PR, follow this guide, but note the following:

• As we squash the commits when merging a PR, there is no need to follow a strict commit organization or write elaborate commit messages for each commit.
  However, when pushing new commits to your PR branch, do clean up new commits (i.e., commits not yet pushed) e.g., delete temporary print statements added for debugging purposes.
• In the PR description, please propose a commit message to be used when the PR is merged eventually. The commit message should follow the guidelines given here. You may refer to this PR for an example.
• For simple documentation fixes or tasks with clear instructions, it is unnecessary to create an issue before creating a PR.
• You can refer to the Architecture and the HTML Report sections to learn about the design and implementation of RepoSense.
• The section below has more information about the various stages of submitting a PR.

Find the suitable pull requests

• If you are contributing to RepoSense for the first time, you can check the list of issues that are suitable for first timers.

• If you are more experienced in contributing, aside from searching for issues in the issue tracker, you can find the list of issues organized in a more systematic way under the Projects Tab of the RepoSense repository. This can help you to find issues with suitable workload and direction.

Following the coding standards

• Make sure you know our coding standards.

• Follow the tutorial to configure Intellij to follow our coding style.
• This project uses Checkstyle to check the compliance of Java code. You can use this document to find how to use it.
  • In particular, run gradlew checkstyleAll to check the style of all the relevant Java code. This will check the Java code in the following order: main code -> test code -> systemtest code.
  • If you only want to check the main code, run gradlew checkstyleMain. Likewise, for test code, run gradlew checkstyleTest and for systemtest code, run gradlew checkstyleSystemtest.
  • You can also run any of the combination of the above, such as gradlew checkstyleMain checkstyleTest or gradlew checkstyleTest checkstyleSystemtest.
• To check Vue files for style errors, run gradlew lintFrontend from the project root directory. You can also run npm run lintfix in the frontend folder to automatically fix some of the JavaScript and CSS lint errors.
• To perform environmental checks for style errors, run gradlew environmentalChecks from the project root directory. This checks if all files end with a newline, if prohibited line endings (\r\n) are present and if trailing whitespaces are present.

Running the app from code

Debugging (front-end)

You can use the hot reloading feature to see how your code changes the functionality of the website in real time.

1. Navigate to the project root in your terminal.
2. Generate the desired data for the report using gradlew run with the appropriate flags.
3. Run gradlew hotReloadFrontend.
4. The website will be automatically opened in your browser shortly.

You can use Vue.js devtools for frontend debugging on Chrome. Here are the steps:

1. On your Chrome, visit the website of Vue.js devtools and add the extension.
2. Go to the detail page of this extension in Chrome's extension management panel and select Allow access to file URLs. If you are unable to locate it, copy the link: chrome://extensions/?id=nhdogjmejiglipccpnnnanhbledajbpd and visit it on your Chrome.
3. Open any report generated by RepoSense.
4. Press F12 or right click and choose inspect at the report page.
5. Choose Vue at the navigation bar.
   
6. Debug using the tool.
   

Testing (front-end)

We use Cypress for automated end-to-end front-end testing.

Writing tests

1. Create a new test file in frontend/cypress/tests.
2. At project root start Cypress Test Runner by running gradlew cypress.
3. Select E2E Testing and choose Chrome as the preferred browser.
4. Under E2E specs, click on the newly created test file to run it.

Running tests

To run all tests locally, run gradlew frontendTest.

• Using the above command, tests are run on the CLI in a headless browser without the report being displayed.
• To run tests in a headed browser, run gradlew cypress then select the test file(s) in the Cypress GUI as shown above.

Testing (back-end)

The back-end tests can be found at [project root]/systemtest and [project root]/test.

Running tests

To run all the system tests, run gradlew systemtest.

To run all the unit and integration tests, run gradlew test.

Writing documentation

This project uses MarkBind for documentation. Follow this tutorial to learn how to use MarkBind for updating project documentation.

To show some content only in the , add the tags="production" attribute to the HTML element enclosing the content. Similarly, tags="dev" will make the content appear only in the .

<span tags="production">This will appear in the production website only.</span>
<span tags="dev">This will appear in the dev website only.</span>
This will appear in both sites.