Skip to content

Latest commit

 

History

History
66 lines (44 loc) · 2.73 KB

testing.adoc

File metadata and controls

66 lines (44 loc) · 2.73 KB
Raw

Testing changes

This document explains how to test changes to the frontend, CI, and rspec-tools.

Refer to the main documentation if you want to modify rules.

Testing the frontend

If your changes are small and noncontroversial, you can directly create a branch in this repository.

However, when you need to show reviewers how the website will look with your changes, you can use a fork with your own GitHub Pages. See Forking for more details.

To test your changes locally, you can start a local HTTP server, such as npm start. Refer to the frontend documentation for more details.

Testing the rspec-tools

Modifications to the rspec-tools do not require any special process. You can therefore use a regular PR from a branch in this repository.

Testing GitHub Actions

There are two strategies to test GitHub Actions: either use your own branch in this repository, or create a fork.

Choose the solution your need based on the impact your changes can have. For example, if the changes may spam/modify other Pull Requests, it is wiser to use your own fork.

Note that GitHub will pick the workflow definitions from your branch whether it is in a fork or not. It will also run new workflow scripts automatically (i.e. there is no configuration to change on GitHub). When working on a new workflow or updating existing ones, since it may confuse other people to see unexpected results, it is preferable to use your own fork while iterating on your work.

See Forking for more details.

Testing Cirrus CI

To test modification to the Cirrus CI script, you need to create your own branch in this repository (not a fork). Cirrus CI will automatically pick up the version of the scripts on that branch.

Forking

Forking this repository is fairly trivial.

  1. Click "Fork" on the top right and select your own account.

  2. If needed, enable GitHub Actions:

    1. in your fork, go to the "Actions" page,

    2. click on the green button to enable workflows,

    3. and, if needed, additionally enable the "Update rule coverage" workflow, which is disabled by default because it executes on a schedule.

  3. If needed, enable GitHub Pages:

    1. enable the GitHub Actions so that the gh-pages branch is properly populated,

    2. go to "Settings" > "Pages" and under "Source"

      • set "Branch" to "gh-pages",

      • select "/ (root)" as the source folder,

      • and click "save".

If you need to rely on GitHub Actions, you can work on your fork’s master branch to ensure that the "Build and Deploy" workflow gets triggered out of the box.

Once you are done with your feature and your PR was merged, you can delete your fork. If you prefer to keep the fork alive, don’t forget to merge the upstream changes before working on your next feature.