Skip to content

Developing

Tibor Šimko edited this page May 10, 2024 · 3 revisions

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 pull request and asking for a review, make sure your commits are well-structured and have a clear message.

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

All commit messages should follow a common style. We are using conventional commits formatting and the commit message headline is important, since it will be used "as is" for release news changelog announcements. Please see commit message style for detailed documentation on the commit style.

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

If not sure, please check the git history of the REANA component you are working on. It will provide you with concrete 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 pull request is a good example of "How to test?" section.

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