Development Notes

Working With Sodar Core

VarFish is based on the Sodar Core framework which has a developer manual itself. It is worth reading its development instructions. The following lists the most important topics:

• Models

• Rules

• Views

• Templates

  • Icons

• Forms

Running Tests

Running the VarFish test suite is easy, but can take a long time to finish (>10 minutes).

cd backend
make test
## OR
cd frontend
make test
## or from root
make test

You can exclude time-consuming UI tests in the backend:

cd backend
make test-noselenium

If you are working on one only a few tests, it is better to run them directly. To specify them, follow the path to the test file, add the class name and the test function, all separated by a dot:

cd backend
pipenv run python manage.py test -v2 --settings=config.settings.test \
  variants.tests.test_ui.TestVariantsCaseFilterView.test_variant_filter_case_multi_bookmark_one_variant

This would run the UI tests in the variants app for the case filter view.

To speedup your tests, you can use the --keepdb parameter. This will only run the migrations on the first test run.

Style & Linting

We use black for formatting Python code, flake8 for linting, and isort for sorting includes. To ensure that your Python code follows all restrictions and passes CI, use

cd backend
## run lint
make lint
## run formatting
make format

We use prettier for Javascript formatting and eslint for linting the code. Similarly, you can use the following for the Javascript/Vue code:

cd frontend
## run lint
make lint
## run formatting
make format

Or, all together (from checkout root)

## run lint
make lint
## run formatting
make format

Storybook

We use Storybook.js to develop Vue components in isolation. You can launch the Storybook server by calling:

cd frontend
## ensure dependencies are the
make deps
## run server
make storybook

Working With Git

In this section we will briefly describe the workflow how to contribute to VarFish. This is not a git tutorial and we expect basic knowledge. We recommend gitready for any questions regarding git. We do use git rebase a lot.

In general, we recommend to work with git gui and gitk.

The first thing for you to do is to create a fork of our github repository in your github space. To do so, go to the VarFish repository and click on the Fork button in the top right.

Update Main

Als refer to Pull with rebase on gitready

git pull --rebase

Create Working Branch

Always create your working branch from the latest main branch. Use the ticket number and description as name, following the format <ticket_number>-<ticket_title>, e.g.

git checkout -b 123-adding-useful-feature

Write A Sensible Commit Message

A commit message should only have 72 characters per line. As the first line is the representative, it should sum up everything the commit does. Leave a blank line and add three lines of github directives to reference the issue.

Fixed serious bug that prevented user from doing x.

Closes: #123
Related-Issue: #123
Projected-Results-Impact: none

Single Commit in PR

Our GitHub repositories are configured to enforce squash commits. That is, all commits in a PR will be squashed into one.

Semantic Pull Requests

We use semantic pull requests / ConventionalCommits.org, enforced by this GitHub Action.

Use one of the following prefixes to get an entry in the README:

• fix: - bug fix, bump patch version

• feat: - feature, bump minor version

The following do not create entries in the README:

• ci: - continuous integration change

• docs: - documentation

• chore: - misc chore

To force the latter to create an entry in the README, add Release-As: THE.NEXT.VERSION in the squash commit message.