Developer Wiki

Welcome to the GaNDLF Developer wiki!

Start

• Full documentation: https://gandlf.org/
• If you are moving from the older CBICA repository, please follow this guide to rebase your current fork.

New releases and making version updates

0. The version file should have the latest development version information. As far as possible, GaNDLF follows Semantic Versioning.
1. Update the version.py file to remove "-dev" from the __version__ variable, and change to whatever number the version needs to be tagged to.
2. Create a new release of the main development branch using the new number referred to in the __version__ variable in the version.py file.

• Choose a tag, which should be the same as the value of __version__ in the version.py file.
  • NOTE: Do NOT tag using git, and use this mechanism to ensure the CD scripts run properly to publish on PyPi.
• Give a meaningful title.
• Use the option "Generate release notes" on GitHub.
• Select appropriate options (usually, just Set as the latest release is fine).
• Publish the release.

3. Update the version.py file to add "-dev" in the __version__ variable, and increase the version number as appropriate. This will be used for nightly publishing of development builds. Ensure that the new version is also updated in all sample configurations and in the testing configurations so that unit tests will pass.

• For simplicity, one can use the gandlf_updateVersion script.
• Note that you should try to do the release and "-dev" version update on the same day, otherwise multiple versions with the "tag" with datestamp will get pushed to PyPi.

4. The CD scripts for nightly and published should take care of pushing to PyPi.

Updating CI/CD tests

Common Installation

0. All common installations are handled by a composite action in this file.
1. For any changes to dependencies, please update the section "Install dependencies and package" in the above file.

Main Tests

0. The main tests are defined in this file.
1. For any changes to the main tests, please update the relevant sections in the above file.
2. It is structured to run parallel tests across different configurations to improve efficiency and reduce overall testing time (refer to this PR for details).
3. The test matrix includes various test groups, each targeting specific aspects of the codebase.
4. Each test group is executed in isolation, allowing for more granular control over the testing process and easier identification of issues.

Adding new tests

0. Refer to other workflows.
1. Check GitHub documentation on this topic.