feat: Support for Platform "Gerrit"

[NiasSt90]

Changes

Allow to use Renovate on the Gerrit-Platform. The Pull-Request-Branch Model of Renovate is translated to Gerrit pre-Submit Model (push to refs/for/).

Context

• Closes #4109

Documentation (please check one with an [x])

• [x] I have updated the documentation, or
• [ ] No documentation update is required

How I've tested my work (please tick one)

I have verified these changes via:

• [ ] Code inspection only, or
• [ ] Newly added/modified unit tests, or
• [ ] No unit tests but ran on a real repository, or
• [x] Both unit tests + ran on a real repository

[Shegox]

I tested this today on our internal Gerrit. First: really awesome stuff and very much looking forward to seeing it in action. Pretty much worked out-of-the-box in my tests.

Take the below please as small user feedback, not sure if that is in anyway feasible to easily implement or even needed :)

On open question we had, and might just be a documentation thing, is how to enable rebasing. Currently it still shows the checkbox, and as far as I know you can't tick/edit the comment on Gerrit?

It might be worth to add some documentation if that works and maybe even adjust the PR-content to mention how to do it to have the information self-contained.

Again many thanks for your work on this, looking forward to seeing Gerrit-support.

---

Edit: I found a way to get it to "rebase/retry" the change. Prefixing the change name (which is the first line of the commit message) with rebase! will force a rebase:

[Shegox]

@NiasSt90 I found that the azure devops platform uses this regex to "massage" the markdown and remove what is not needed. Maybe we can do something similar for removing the rebase checkbox and replace it with "Prefix the commit message with rebase! to force a rebase/retry." statement.

https://github.com/renovatebot/renovate/blob/af3b2038f877d7c5656b0da276a8b40ff918f22b/lib/modules/platform/azure/index.ts#L741-L750

[NiasSt90]

@NiasSt90 I found that the azure devops platform uses this regex to "massage" the markdown and remove what is not needed. Maybe we can do something similar for removing the rebase checkbox and replace it with "Prefix the commit message with rebase! to force a rebase/retry." statement.

https://github.com/renovatebot/renovate/blob/af3b2038f877d7c5656b0da276a8b40ff918f22b/lib/modules/platform/azure/index.ts#L741-L750

I've seen this. But it feels more like a hack than a good solution. But as a last resort this could be used.

To your other "rebase.." question/answer:

if you can edit the commit-msg from the Gerrit-ui why you don't click on the rebase button to enforce a rebase?

How your "rebaseWhen" configuration looks like during your Gerrit-Tests?

[Shegox]

To your other "rebase.." question/answer: if you can edit the commit-msg from the Gerrit-ui why you don't click on the rebase button to enforce a rebase? How your "rebaseWhen" configuration looks like during your Gerrit-Tests?

For pure "git native" rebase the UI thing is sufficient. What I normally use the retry/rebase checkbox for is to actually retry a change. E.g. to explicitly tell Renovate, please recreate this change with the latest information now. This might be different from just a rebase.

This might be necessary if Renovate failed during the creation with an error like below (that explicit message is from GitHub, but the same can happen on Gerrit as well):

Anyway I think the current setup with the commit message fully satisfies this and it is probably just about documenting it.

[NiasSt90]

To your other "rebase.." question/answer: if you can edit the commit-msg from the Gerrit-ui why you don't click on the rebase button to enforce a rebase? How your "rebaseWhen" configuration looks like during your Gerrit-Tests?

For pure "git native" rebase the UI thing is sufficient. What I normally use the retry/rebase checkbox for is to actually retry a change. E.g. to explicitly tell Renovate, please recreate this change with the latest information now. This might be different from just a rebase.

This might be necessary if Renovate failed during the creation with an error like below (that explicit message is from GitHub, but the same can happen on Gerrit as well):

okay, rebuilding the complete change from current baseBranch is the same what is actually done with rebaseWhen=auto and Gerrit.getRepoForceRebase=true. Therefore i'm wondering why a manual rebase/rebuild is needed.

See here for some details about the current default behavior, the comment was gone to the wrong conversation.

Anyway I think the current setup with the commit message fully satisfies this and it is probably just about documenting it.

okay, the commit-msg (prTitle) was checked independent of the rebaseWhen configuration.

[rvarun11]

Any update on this getting merged anytime soon?

[viceice]

• Blocked by #19327

[NiasSt90]

For testing purpose i've pushed the current status (based on #19065) to this branch.

Improvements:

• no special configuration needed anymore (neither gitNoVerify nor platformCommit)
• better markdown handling (some replacements specific to Gerrit: PR -> Change-Request, ...)

[NiasSt90]

I've updated this branch to the latest version of https://github.com/renovatebot/renovate/issues/19065.

We are coming closer to a final version ;)

[NiasSt90]

hi, i've added the StabilityDays feature to my Gerrit implementation (one of the last TODOs). (and the upcoming? feature Merge-Confidence too).

I have converted the BranchStatus renovate/stability-days to a Gerrit-Label with currently fixed name Stability. If the label exists it would get the max/min value according to the state (green == max, yellow/red == min). There is no special submit-rule needed for this label, renovate will query the label and prevent automerge accordingly.

This can look like this (in my case Stability has a submit-rule applied and Merge-Confidence not):

Now i have some questions to other Gerrit users: Is this a practicable? What further configuration will be required or useful?

[tobias-urdin]

Just crossing my fingers 🤞 over here hoping to add renovatebot to our projects if this is merged 👍 Nice work!

[viceice]

the git changes PR is nearly done, then we can continue here

[sselberg]

Now i have some questions to other Gerrit users: Is this a practicable? What further configuration will be required or useful?

Potentially there's an issue with the general "Stability" as a label. Potentially this label is already used by some Gerrit instances. Would it make sense to rename it to "Renovate-Stability" or make the label configurable?

Awesome work!

[NiasSt90]

Now i have some questions to other Gerrit users: Is this a practicable? What further configuration will be required or useful?

Potentially there's an issue with the general "Stability" as a label. Potentially this label is already used by some Gerrit instances. Would it make sense to rename it to "Renovate-Stability" or make the label configurable?

they are both configurable now.

This PR now is based on the (finished) PlatformSCM refactoring and in my opinion it's feature-complete now. I'm still testing and perform some minor refactorings.

[Hartorn]

Hey,

Looking forward to see this work integrated soon, as we are also using Gerrit !

I was wondering how I could try this in a docker before it would be released. I try to look into Renovate repository, but it looks like docker image is built only based on released version. Am I missing something ?

[viceice]

you can run from source and set binary source to docker, so that required tools don't inferre with your local machine

[felipecrs]

@NiasSt90 maybe you have said this already somewhere else, but:

Have you considered using a commit message footer to store the branch name as opposed to hashtags?

Like:

Upgrade dep x to v2

Change-Id: Something
Renovate-Source-Branch: dep-x-v2

I find it a little less intrusive than hashtags, and would also come in handy for people with Gerrit without NodeDb.

[NiasSt90]

@NiasSt90 maybe you have said this already somewhere else, but:

Have you considered using a commit message footer to store the branch name as opposed to hashtags?

Like:

Upgrade dep x to v2

Change-Id: Something
Renovate-Source-Branch: dep-x-v2

I find it a little less intrusive than hashtags, and would also come in handy for people with Gerrit without NodeDb.

Hmm, should be doable, but to retrieve the commit message (for utils.extractSourceBranch(change: GerritChange)) we need a separate rest-call because ChangeInfo.subject contains only the first line of the commit message.

The rest should be easy:

• add a line to commit-message in scm.commitAndPush
• change GerritClient.buildSearchFilters to search for "message:.." instead of "hashtag:.."

Because of the additional rest-call, i don't wanna do this for the first release. I'm think that i'm too close to release/finish this PR to start over again. And i'm not completely sure that my above idea works (i have no Gerrit 2.x version ready to test this).

[felipecrs]

Hmm, should be doable, but to retrieve the commit message (for utils.extractSourceBranch(change: GerritChange)) we need a separate rest-call because ChangeInfo.subject contains only the first line of the commit message.

In the query command you can ask for the commit message with: /changes/?q=<query>&o=CURRENT_REVISION&o=COMMIT_FOOTERS (and this works with 2.x and 3.x).

[
  ...
  {
    "change_id": "I86ea2be2de26dccfbfaca0722d530737cf09932a",
    "subject": "Upgrade mvn to 2",
    "current_revision": "10d0db7da3fc0023789314fa7e22702f5ed1f8a1",
    "revisions": {
      "10d0db7da3fc0023789314fa7e22702f5ed1f8a1": {
        "ref": "refs/changes/93/15412793/1",
        "commit_with_footers": "Upgrade mvn to 2\n\n- This is an automatically generated GCR.\n\nChange-Id: I86ea2be2de26dccfbfaca0722d530737cf09932a\n\n"
      }
    }
  }
]

I also totally think you should leave Gerrit 2.x out of the picture, especially for the first release. But I think this would be the kind of change that could not be made easily after the first release, as otherwise we would have to probably have code to handle the migration of old change requests using the hashtag to this new approach, or query for both things when searching for existing change requests.

[NiasSt90]

Hmm, should be doable, but to retrieve the commit message (for utils.extractSourceBranch(change: GerritChange)) we need a separate rest-call because ChangeInfo.subject contains only the first line of the commit message.

In the query command you can ask for the commit message with: /changes/?q=<query>&o=CURRENT_REVISION&o=COMMIT_FOOTERS (and this works with 2.x and 3.x).

interesting. i will take a look at it.

But currently there is another major problem, the onboarding dont work anymore. In https://github.com/renovatebot/renovate/pull/20893 the scm.checkoutBranch() was replaced with a git.mergeBranch() call where the existence of a remote branch is assumed.

[viceice]

will try Todo another full review next week.

[rvarun11]

I was testing the PR and found that prHourlyLimit does not work as expected. It creates all the GCRs (PRs) possible.

Here's a pastebin link to the logs: https://pastebin.com/raw/bPTh72AC

It can be noted that the logs do say Reached PR limit - skipping PR creation but all the PRs are still created. Here's the output:

As you can see that all the possible PRs were created. I tested the same configuration on GitHub and it works as expected (creating only 5 PRs).

[NiasSt90]

Thanks for testing.

I was testing the PR and found that prHourlyLimit does not work as expected. It creates all the GCRs (PRs) possible.

Found and fixed. It was a caching issue for the "branches" limit.

    if (!branchExisted && (await scm.branchExists(branch.branchName))) {
      incLimitedValue('Branches');
    }

The Gerrit scm.branchExists function relied on cached results and the limit for branches was not increased.

It can be noted that the logs do say Reached PR limit - skipping PR creation but still all the PRs are still created.

Yes the broken version don't try to create PRs but still try to create branches. And for Gerrit this means create implicit PRs because there are no branches used for PRs.

[rarkins]

@NiasSt90 what's the current status of this PR - do you think it's ready for final review for merging, or is there still major work remaining?

[NiasSt90]

@NiasSt90 what's the current status of this PR - do you think it's ready for final review for merging, or is there still major work remaining?

Sure, it's been ready for the final review for a long time.

[panicking]

@NiasSt90 I would like to test it, can you please give some small information in how to test it and summarize the status?

[NiasSt90]

@panicking

@NiasSt90 I would like to test it, can you please give some small information in how to test it and summarize the status?

hmm i think nothing special, more or less like:

1. checkout the PR
2. create a renovate config.js according to your needs, for the Gerrit-Credentials read lib/modules/platform/gerrit/index.md
3. run renovate (pnpm run start) multiple times
4. check the created Changes in your Gerrit server

i would limit the configuration to a single Gerrit-repository only.

[felipecrs]

If you don't have a Gerrit instance, you can probably try on https://review.gerrithub.io/.

[CLAassistant]

All committers have signed the CLA.

[hanson76]

Been watching this PR for some time hoping for it be merged and included a release. It will allow us to get rid of our internal script based solution that has lot of limitations.

Any idea how far away it is to be accepted into a release?