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:
Running the VarFish test suite is easy, but can take a long time to finish (>10 minutes).
$ make test
You can exclude time-consuming UI tests:
$ 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:
$ 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
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
$ make black isort flake8
$ make vue_lint prettier
Or, all together:
$ make black isort flake8 vue_lint prettier
We use Storybook.js to develop Vue components in isolation.
nmp i in
varfish/vueapp, you can launch the Storybook browser by calling:
$ 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
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.
$ 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
$ 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
Cleanup Before Pull Request
We suggest to first squash your commits and then do a rebase to the main branch.
Squash Multiple Commits (Or Use Amend)
We prefer to have only one commit per feature (most of the time there is only one feature per branch). When your branch is rebased on the main branch, do:
$ git rebase -i main
Alternatively, you can always use
git commit --amend to modify your last commit.
This allows you also to change your latest commit message.
Rebase To Main
Make sure your main is up-to-date. In you branch, do:
$ git checkout 123-adding-useful-feature $ git rebase main
In case of conflicts, resolve them (find
<<<< in conflicting files) and do:
$ git add conflicting.file $ git rebase --continue
If unsure, abort the rebase:
$ git rebase --abort
Push To Origin
$ git push origin 123-adding-useful-feature
In case you squashed and/or rebased and already pushed the branch, you need to force the push:
$ git push -f origin 123-adding-useful-feature