retest / rebazer Goto Github PK

Prviously, a merge message looked like

Merged in fix/not-selected-combo-box (pull request #723)

Fix combobox selection according to specification

Approved-by: Johannes Dillmann <[email protected]>

which contained information about the branch name and pull request number. That information is in the current version of the merge message missing. Can we readd it to something like (suggestions):

Merged in fix/not-selected-combo-box (pull request #723) by ReBaZer

ReBaZerConfig should be adapted such that multiple repositories can be defined. Therefore, we should also change how the external configuration takes place. For instance, Spring Boot also supports YAML:

rebazer:
   user: service_user
   pass: dont_use_this_pass_at_home
   team: your_company
   workspace: ./rebazer-workspace
   repos:
       - foo
       - bar
       - baz

Before PR#99 rebazer crashed when trying to checkout an external PRs branch which does not exist in our origin repository. We should discuss how we want to handle this within rebazer:

• Ignore the handling of external PRs
• Don't try to rebase external PRs, but merge if conditions are met
• ...

First, we should adapt the log level globally. For instance, processing a repo or a pull request should be on DEBUG level.
Second, we should use parameterized messages via the SLF4J API.

It didn't return the last commit, because it don't uses the last page. Fix: Get the actual last page, not just the last of 10 or increase the number of commits in json to display all.

Addon: Fix the misleading name of the method, e.g. getParentIdOfFirstCommitInBranch.

During compile-time these warnings are shown:

[WARNING] GithubConnector.java:[25,35] basicAuthorization(java.lang.String,java.lang.String) in org.springframework.boot.web.client.RestTemplateBuilder has been deprecated
[WARNING] BitbucketConnector.java:[27,49] basicAuthorization(java.lang.String,java.lang.String) in org.springframework.boot.web.client.RestTemplateBuilder has been deprecated
[WARNING] BitbucketConnector.java:[29,43] basicAuthorization(java.lang.String,java.lang.String) in org.springframework.boot.web.client.RestTemplateBuilder has been deprecated

When no builds have been configured (yet), let the rebazer still work just when someone approved it. There were some ideas flying around how to implement it (e.g. is there a special result when asking for build status, ... ).

However this may result in that there will be no changes on some hosts if there is no build, thus the logic for merging would need refactoring.

Sometimes repos can be really big this can cause different problems, so we should monitor that

We currently get a huge stack trace if a PR can't be merged on GitHub. Therefore we should properly log the root cause if we receive a 405 error.

[WARNING] unable to get access token for Google Container Registry, configuration for building image will not contain RegistryAuth for GCR
java.io.IOException: Error code 404 trying to get security access token from Compute Engine metadata for the default service account. This may be because the virtual machine instance does not have permission scopes specified.

Cause is probably that on the travis build vm image contains some magic ENV variables or GCR build tools. This triggers the automatic support of the GCR in the docker plugin.

https://developer.github.com/v3/checks/runs/

https://blog.travis-ci.com/2018-09-27-deprecating-github-commit-status-api-for-github-apps-managed-repositories

The API now supports creating comments on pullrequests for the v2 Endpoint[0]. Therefore we can migrate all code using the legacy template to the new one.

[0] https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Busername%7D/%7Brepo_slug%7D/pullrequests/%7Bpull_request_id%7D/comments

Seems like the rebazer also tried to rebase this hotfix branch: retest/recheck#257.

Do we want to logging informations in a separate slack channel?

https://github.com/maricn/logback-slack-appender
https://github.com/wpic/logback-slack-appender

Current log locks like:

...
Dec  1 17:11:59 rebazer rebazer[6507]: 2017-12-01 17:11:59.598  INFO 6509 --- [taskScheduler-1] o.r.rebazer.service.BitbucketService     : Processing PR976 ( feature/generic-launcher -> develop )
Dec  1 17:11:59 rebazer rebazer[6507]: 2017-12-01 17:11:59.819  INFO 6509 --- [taskScheduler-1] o.r.rebazer.service.BitbucketService     : Waiting for green builds on PR976 ( feature/generic-launcher -> develop )
Dec  1 17:11:59 rebazer rebazer[6507]: 2017-12-01 17:11:59.819  INFO 6509 --- [taskScheduler-1] o.r.rebazer.service.BitbucketService     : Processing PR977 ( feature/RET-1107-robust-rmi -> develop )
Dec  1 17:12:00 rebazer rebazer[6507]: 2017-12-01 17:12:00.500  INFO 6509 --- [taskScheduler-1] o.r.rebazer.service.BitbucketService     : Waiting for rebase on PR977 ( feature/RET-1107-robust-rmi -> develop )
Dec  1 17:12:00 rebazer rebazer[6507]: 2017-12-01 17:12:00.500  INFO 6509 --- [taskScheduler-1] o.retest.rebazer.service.RebaseService   : rebase PR977 ( feature/RET-1107-robust-rmi -> develop )
...

Should not happen:

[retest/rebazer] Feature/better exception handling (#47)
Rebase failed, this pull request needs some manual love ...

[retest/rebazer] Feature/better exception handling (#47)
@roesslerj approved this pull request.

[retest/rebazer] Feature/better exception handling (#47)
Merged #47 into develop.

The following PR got merged although changes were requested:

retest/recheck#240

I would expect a single change request to block a PR from being merged, even if other reviewers approved.

We currently receive quite a lot rebazer comments on Bitbucket where rebasing fails. The logs say "Local repository isn't prepared for Repo […]".

We should also support GitHub since we have repositories here as well. GitHub has webhooks, hence, we don't need a polling strategy.

As default I like one approval, but sometimes I want explicit that all approver must review the code.

I suggest implementing a support of '@ALL' in the title of a pull request. Benefits:

• It's visible in the overview of pull requests
• Simple to implement
• Works with all type of git hosting platforms