The SlicerExecutionModel is a CMake-based project providing macros and associated tools allowing to easily build Slicer CLI (Command line module).
It is designed to improve the acceptance and productivity of Slicer application developers. The Execution Model provides a simple mechanism for incorporating command line programs as Slicer modules. These command line modules are self-describing, emitting an XML description of its command line arguments. Slicer uses this XML description to construct a GUI for the module.
SlicerExecutionModel is documented here:
https://www.slicer.org/wiki/Documentation/Nightly/Developers/SlicerExecutionModel.
There are many ways to contribute to SlicerExecutionModel, with varying levels of effort. Do try to look through the documentation first if something is unclear, and let us know how we can do better.
We encourage a range of contributions, from patches that include passing tests and documentation, all the way down to half-baked ideas that launch discussions.
If you are new to SlicerExecutionModel development and you don't have push access to the SlicerExecutionModel repository, here are the steps:
This corresponds to the Fork & Pull Model
mentioned in the
GitHub flow guides.
If you have push access to SlicerExecutionModel repository, you could simply push your branch
into the main repository and create a Pull Request. This
corresponds to the Shared Repository Model
and will facilitate other developers to checkout your
topic without having to configure a remote.
It will also simplify the workflow when you are co-developing a branch.
When submitting a PR, make sure to add a Cc: @slicer/slicerexecutionmodel
comment to notify SlicerExecutionModel
developers of your awesome contributions. Based on the
comments posted by the reviewers, you may have to revisit your patches.
When you submit a PR to the SlicerExecutionModel repo, CircleCI will run the build and test suite on the head of the branch. If you add new commits onto the branch, those will also automatically be run through the CI process. The status of the CI process (passing, failing, or in progress) will be displayed directly in the PR page in GitHub.
The CircleCI build will run according to the .circleci/config.yml file, which is useful as an example for how to set up your own environment for testing.
Your test results will be posted on SlicerExecutionModel's dashboard. These results will list any failed tests. You can reach your build by clicking the build status link on your GitHub PR.
With each PR, SlicerExecutionModel is built and tested against multiple version of ITK. Each environment is made available in docker images:
Dockerfile
found in a Docker-ITK-vX.Y.Z
subdirectory of test.Deprecated environments are not maintained, corresponding Dockerfiles have been deleted and associated SlicerExecutionModel continuous integration settings have been removed.
To add a testing environment:
test/Docker-ITK-vX.Y.Z[_qualifier]
)Dockerfile
DIRECTORIES
in test/Docker/MakefileREADME.md
To update a testing environment:
test/Docker-ITK-vX.Y.Z[_qualifier]/Dockerfile
Then, after adding or updating an environment, build and publish images:
cd test/Docker
make push
And finally, create a PR with your changes.
Getting your contributions integrated is relatively straightforward, here is the checklist:
All tests pass
Consensus is reached. This requires that a reviewer adds an "approved" review via GitHub with no changes requested, and a reasonable amount of time passed without anyone objecting.
Next, there are two scenarios:
Then, click on the "Delete branch" button that appears afterward.
See http://www.slicer.org/copyright/copyright.txt for details.
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.