Developing

This page summarises our principles and practices when developing code.

Self-assign to the issue

Issues describe work that needs to be done. Whatever it is a bug to fix or feature to develop. When you decided to work on some issue, make sure you assign yourself to it. It allows team members and collaborators to see who is working on which issue.

Development flow

After you know what is your issue, you can proceed to development. We develop using the fork and pull model on GitHub. Make sure you are comfortable with the model. No need to be an expert, just have a good grasp on it. You can learn more about it from GitHub documentation.

The development flow looks like this:

1. You create a branch in your fork.
2. You can freely develop and experiment with your branch.
3. When you decide that your branch is ready to be merged, you should open PR in one of the REANA repositories.
4. Someone from REANA team will review it.

Below you can find more details on how we develop code for REANA.

Debugging

While working on a codebase, you will definitely need to debug it to better understand what is going on. For these purposes, we have a dedicated page that will explain to you how to debug REANA code.

Structure and style of commits

Before finalizing your PR and asking for a review, make sure your commits are well-structured and have a clear message. Please follow the rules below:

A single commit should contain one logical change. If a single PR introduces multiple logical changes, create multiple commits.

All commit messages should follow a common style. The current template looks like this:

<affected-module>: <short-description-of-change>

<more-detailed-description-if-needed>

<link-to-issue-if-exists> 

For example, commit message can look like this:

auth: migrate to the new SSO 

Changes invenio oauthclient contrib to cern_openid which enables the new SSO usage

closes #480

Check GitHub documentation to learn about how to link to issue in your commit message. Note: The above documentation describes how to link issue to pull request, but it also works for a commit message.

If not sure, feel free to check the git history of some REANA components. It will provide you with more examples of how we style the commits.

Add help section to pull request before asking for review

Add "How to test?" section to explain steps reviewers need to take to test your code changes. It makes their life easier, and reviewing process faster. This PR is a good example of "How to test?" section.

Now when your pull request is ready, it is time to proceed for Reviewing.