Re: Git workflows
Greetings,toggle quoted messageShow quoted text
Coming into this a little late.
On 8/9/22 13:58, Robert Varga wrote:
1. Support for multiple branchesThis is still accurate AFAIK. Change-ID is very much a Gerrit concept which they leverage heavily to understand the status of any given change across the status of all branches.
That all being said, there is the ability to pull GitHub PRs into Gerrit. The problem with this being as follows:
1. It's a manual process by way of a plugin in Gerrit that has to be initiated by someone that is expectings a PR that needs to come in.
2. Change-ID isn't something that is enforced by GitHub, it could be semi-enforced by a GitHub Action, but all that would do is mark the PR as not passing, so it's not true enforcement. GitLab, on the other hand, _could_ enforce this because it's possible to setup a regex filter on commit messages that must be passed to even raise an MR, but there's other downsides to that (including LFRE not having any job integration currently with GitLab and Jenkins, though it's possible).
Doing the Change-ID work by a GitHub Action or bot may be a solution for reflecting changes back into Gerrit, but you're still going to run into some weird edge cases.
2. PermissionsTechnically, we have something comprable on the GitHub side using INFO.yaml. However, absolutely no project that we support in GitHub has elected to utilize it as it ended up being harder to work with than the INFO files as they currently exist in repo. Mostly because the implementation pulled it out of the repos themselves and stuck it into a side repo inside the Org. The reasons for this are varied but mostly come down to how easy it was to detect changes to the remote INFO files that needed to be then be shadowed into the LF's releng/info-master repository.
3. VerificationLF managed Jenkins already supports GitHub as a source SCM triggering into Jenkins. In point of fact all of the global-jjb core jobs that ODL utilizes have two variants, a Gerrit variant and a GitHub variant. The primary issue being that you can't have both variants active for a given repository at the same time because namespace collisions.
There was an idea floated not long ago internally about if it would be possible to sort of go the other way Gerrit -> GitHub with work still primarily happening in Gerrit (changes raised, etc) but cause Gerrit changes to raise PRs into the GitHub mirror to then trigger GitHub Actions that would then somehow have the results shuttled back to the Gerrit Change.
I believe this would be doable, but nobody has had the time to sit down and evaluate how to actually make it work.
The best scenario would be that changes could be raised on either side (Gerrit or GitHub) and that review itself would just continue to happen in Gerrit along with the final merges. Getting bi-directionality would be a major project though.
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation
NOTICE: The Linux Foundation supports their employees with flexible work
hours. If you recieve mail from me outside of standard business hours
please be aware that I do not expect a response until the next standard