Code development workflow

1 Adding new code to the repository

We use the workflow of adding new code to the repository described in The Code Review process section of ICM wiki. It's main characteristics are that:

• a new feature branch is created for developing new functionalities,
• after the feature branch is completed, its code is being reviewed and merged with master branch and the feature branch is deleted
• the resulting history of the source code is linear.

1.1 Adding OpenAIRE2020 project's partner code

When adding code authored by ARC partner from the OpenAIRE2020 project (this partner provides code supporting madIS system used within IIS), we diverge slightly from the model described in The Code Review process section of SAOS project's wiki. Namely, we don't create a pull request and don't inspect rigorously the code. We assume that the code has already went through a quality assurance process and we usually only check that IIS'es integration tests pass before pushing this code to the master branch.

When committing such a change, we set a particular person from the partner organization as the author of the commit (git commit --author="Name Surname <[email protected]>").

2 Commit messages

The commit messages should have a form of, e.g. Closes #1234: Add new search method, Closes #15: Operating system independent unit tests. This means that the first line:

• Should start with Closes #$ISSUE_NUMBER: $REAL_COMMENT if the commit closes an issue with number $ISSUE_NUMBER.
• Should use present tense and imperative form or be just a description of the implemented functionality.
• Should be no longer than 70 characters (this is the length of the message that is shown by default by GitHub, Vim also warns you if you want to make the line longer).

Apart from that, you can place more detailed comments related to the commit in consecutive lines of the description.

3 Using GitHub Issues and Redmine

We use two issue trackers: GitHub Issues and Redmine.

• GitHub Issues stores issues related directly to introducing some changes in the code.
• Redmine stores issues where new potential changes are discussed and specified. Redmine issues are usually less specific than those on GitHub. As a result, one Redmine issue might be a parent of couple GitHub issues.

In order to somehow marry these two separate issue tracking systems we do what follows.

• Each pull request is related to some GitHub issue. It usually closes a given GitHub issue.
• If the commit or GitHub issue is related to some Redmine issue, this should be stated explicitly by referring to Redmine issue using notation redmine:1234, where 1234 is the number of the ticket from Redmine.
  • In case of a commit, this reference should be placed in one of the lines below the first line of the description of the commit.
  • In case of a GitHub issue, this reference should be placed in the description of the issue (but not in the title).