The best way to familiarise yourself with the internals of OpenCOR is by having a look at its source code.
All of the source code is and must be made available under the
OpenCOR namespace (e.g.
[OpenCOR]/src/mainwindow.h). There are only two exceptions to this rule:
[OpenCOR]/src/windows/main.cpp (i.e. OpenCOR's two main
All changes to the source code must be referenced in the list of issues using labels. There are three types of labels:
Whenever something is pushed to the master branch, OpenCOR gets automatically built and tested on Travis CI's Ubuntu and macOS machines. That is, unless
[ci skip] has been added to a commit message, although a commit that closes an issue should always result in OpenCOR being built and tested on Travis CI.
However, it is not recommended to work directly on the master branch. Instead, anyone wanting to contribute to OpenCOR should first fork its Git repository. Then, a new branch called
issueXXX should be created for issue
#XXX. It will contain the work associated with issue
XXX. The work completed, a pull request should be made. This pull request will trigger OpenCOR to be built and tested on Travis CI. Assuming it all goes fine, it will then be up to the project manager to merge the work.
Upon merging a pull request, OpenCOR will also be built and tested through Jenkins at the Auckland Bioengineering Institute, and this on Windows, Linux and macOS.
More specific information can be found in the following pages: