[releng] Create an EGit Genie

[tomaswolf]

Description

The Eclipse Foundation used to have the "Eclipse Genie" that helped maintaining traceability between Bugzilla issues and Gerrit.

We should have something similar for our GerritHub setup.

• When an initial change (PS 1) appears in Gerrit and the commit message has a "Bug: egit-xx" footer, add a comment to issue xx here in Github with the GerritHub change URL.
• Perhaps: whenever a Gerrit change is submitted and the commit message has a "Fixes: egit-xx" footer, auto-close Github issue xx.
• Perhaps even: when a release is done, go through all commits since the last release tag, look for "Fixes: egit-nn" footers, and if so, add all these Github issues to a milestone for the release. Or perhaps do that individually whenever such a change is merged.

This would need a Jenkins credential for a Github token that could be used to authenticate to the Github API. Operations could then be done via curl in Jenkins jobs triggered on appropriate conditions (change pushed, merged, ...)

Motivation

Reporting Gerrit changes in issues improves traceability. Adding fixed issues to milestones gives us a way to list all issues resolved in a release.

Alternatives considered

Currently, all these operation have to be done manually, which is easy to forget.

Additional context

No response

[tomaswolf]

One potential stumbling stone: what are the API limits (rate limits) that our Jenkins would be subject to?

[msohn]

Another option would be to implement a Gerrit plugin based on its-base [1] similar to the its-jira plugin [2]. There is already an empty its-github repo [3] where this could be implemented.

• [1] https://gerrit.googlesource.com/plugins/its-base/+/refs/heads/master/
• [2] https://gerrit.googlesource.com/plugins/its-jira/+/refs/heads/master
• [3] https://gerrit-review.googlesource.com/admin/repos/plugins/its-github,branches

[tomaswolf]

Yes, that's another possibility. Don't know what would be better or easier to implement or maintain.

A Gerrit plug-in would also need an API token, which probably would have to come from the Eclipse Foundation since they own the repo/the organization? The load of doing these Github API calls would be on Gerrit, and that plug-in would need to be installed in Gerrit. It might also be subject to rate limits on the Github API. The solution would be specific to Gerrit. OTOH, it might provide an easy solution for other interested parties.

Doing it with Jenkins jobs would mean the Eclipse Foundation can set up the Jenkins credential, we could define our jobs, and the actual API calls would be off-loaded from Gerrit to some Jenkins agent (which would have to be fired up first, so overall there might be more work, but it wouldn't contribute to the load on the Gerrit server). The solution would be independent of Gerrit; only prerequisite would be that there is something in Jenkins that triggers build on Gerrit events, and that already is there.