Skip to content

Developing

Vladyslav Moisieienkov edited this page Jun 16, 2022 · 3 revisions

This page summarises our principles and practices when developing code.

Development flow

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.

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

Self-assign to the issue

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.

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.