Helper service to handle pull requests (PRs) on GitHub or Bitbucket. Primary it rebases the source branch of PRs against target branch to streamline commit history.

The rebazer polls in a configurable interval GitHub and Bitbucket repositories. The processing for each repository is described below:

• Has PR changed since last run?
  • If no wait again for source/target branch, build result or approval change
• Is the corresponding build green?
  • If no wait again for green build
• Is source branch on top of target branch?
  • Rebase source branch
  • Conflict while rebasing?
    • On conflict abort rebase and comment PR
  • Wait for green build
• Is PR approved?
  • Wait for approval
• Merge PR into
• Delete merged branch

Illustrated as a flowchart:

The rebazer relies on several parameters to configure the handled repositories. The configuration can be specified in any way supported by spring boot. Recommended is to use a application.yml file. The roll out of the application.yml depends on type of deployment.

Minimal configuration example:

rebazer: hosts: - type: GITHUB teams: - name: your_company user: service_user pass: dont_use_this_pass_at_home repos: - name: foo - name: bar

An example in-depth can be found in application-example.yml.

This JAR can basically be run everywhere a JVM is present; there are no further dependencies. However, for a successful start, several parameters need to be configured (see configuration section for details). There are quite a number of ways to specify these parameters.

If e.g. all parameters are specified in a file called application.yml, the following command should be sufficient for starting rebazer:

java -jar rebazer-VERSION.jar --spring.config.location=file:./application.yml

There exist a docker image on docker hub. An example configuration for the docker container is placed in the docker-compose.yml.

To configure the rebazer mount the configuration file at /application.yml. To optimize production setups it is recommended to mount /rebazer-workspace as a external storage or ram disk.

Attention: We don't ship a fully functional configuration for this package. So after installation, one must ensure that a proper configuration is placed in /etc/rebazer. Also make sure that the configuration file is accessible by the user rebazer.

This package automatically creates:

• System user for running rebazer
• Proper logging via systemd/syslog (to /var/log/rebazer)
• Systemd service named rebazer.service
• Workspace in /var/lib/rebazer (can be configured in /etc/defaults/rebazer)

The debian package overwrites the rebazer.workspace parameter via an environment variable.

Symptom: Errors during startup

Solution: Please make sure the folder /etc/rebazer contains a valid configuration and the user rebazer has access to it.

chmod 755 /etc/rebazer
chmod 600 /etc/rebazer/application.yml
chown rebazer:rebazer /etc/rebazer/application.yml

Before building the rebazer application, please make sure that the following tools are installed:

• Java 8
• Maven (3.3+)
• Git

A typical build involves calling the package target via maven from the root of the cloned repository:

mvn clean package

The major artifacts are then build inside the target directory: rebazer-$VERSION.jar.

There are maven profiles to build docker or deb packages.

mvn clean package -P deb

mvn clean package -P docker

mvn clean package -P deb,docker