Customization Service¶

The Customization Service (CS) is built on top of our Brander and available to specific customers. It allows the customer to modify the clients to their needs, without the need of forking and maintaining it all alone.

How it works¶

The customer maintains a repository with all changes as Pull Requests, targeting the desired upstream branch.

The CS is then performing these steps

• updating customer's master/main branch
• check out specified tag or master/main branch
• apply all changes from Brander (name, color, changing assets)
• retrieving all Pull Requests from customer's repository matching the target
  • only PRs with label "approved" will be used
  • git merge with strategy "union"
  • fail if PR cannot be applied
  • else continue with next PR
• upload all changes as new branch "customized-$tag" (e.g. customized-master or customized-stable-3.30)
• compile build artifacts as with Brander

Setup / Access¶

The additional Customization Service needs to be enabled by Nextcloud. Then it is accessible via https://portal.nextcloud.com/brander.

The customer needs to provide a link to a GitHub repository for each client.

The logged in user can then build for all clients the specified versions:

Maintain PRs¶

All changes need to be Pull Requests targeting main/master branch. This allows the customer to see on a daily basis, if all their changes still apply, even when upstream is changing something. It is the responsibility of the customer to have the PRs in a mergeable state.

New version¶

If Nextcloud publishes a new version, then all PRs that should be in this new version must be "backported". The command "/backport to $branch" (e.g. "/backport to stable-3.30") can be used. This allows to have a different patchset for each versions.

Pull Requests targeting an old version can then be closed and removed.

Best practice¶

• Contrary to a normal PR, it is better to combine changes by changed files in one PR. So all modifications affecting translation should be in one file. Otherwise problems with "git merge" can happen
• Modifications should be kept to a minimum: only when a change cannot be upstreamed (integrated to Nextcloud) a PR should be created
• add "[$targetBranch]" to PR name, e.g. "[master] Data processing agreement"

Example¶

A working example can be found here:

• PR "[stable-3.23] minor translation" is targeting stable-3.23 branch
• PR "[master] Drawer changes" and "[master] always enable strict mode" are targeting master branch and can be backported to a new version