Hi Jürg, > On Tue, 2020-09-01 at 22:22 +0100, Chandan Singh wrote: > > * Issues // automated-migration > > > > We can use the node-gitlab-2-github tool [0] that we tried earlier [1]. We > > should be able to preserve the issue references, but all issues/comments > > will > > be authored by the user that ran the migration tool. > > We should create a neutral GitHub account for the import to reduce > confusion with regards to issue and comment authorship.
Definitely +1 for a separate account. > The issue numbers stay the same, correct? I.e., not only references > between issues but also issue references in commit messages and mails > will be preserved. That's correct, issue numbering is preserved and the references should work fine from commits etc as well. With the obvious caveat that the references would only go to the GitHub issue if the short form (#number) was used, and not if a full issue link was used. > > * Merge requests // automated migration* > > > > Merge requests can be migrated as pull requests using the same > > node-gitlab-2-github tool. However there's a `*` here because references > > to > > merge requests will NOT be preserved. > > > > To clarify, it will not be the case that any references are pointing to an > > unrelated issue. Rather, the `!` prefix is not considered "special" by > > GitHub > > so it will just be rendered literally. > > As far as I know, the merge requests will be renumbered (unlike > issues). I understand that `!` MR references will not automatically be > replaced. However, can we at least provide developers a way to manually > lookup the new GitHub PR number from a GitLab MR number? Could simply > be a table of GL MR -> GH PR mappings. Or could we add the old !MR > number to the title of each migrated GitHub PR? I think such a table might be useful as it'll work both ways. This table could then also be used to add a comment if we want that. I can't remember now, but I think node-gitlab-2-github outputs this info as part of its logs. Even if it doesn't, it should still be easy enough to create such a table, as the numbers should be increasing monotonically on both sides. (node-gitlab-2-github will create all issues first, and then the PRs) > > * marge-bot // drop // use Actions > > > > Our favorite marge-bot doesn't deal with GitHub pull requests as far as I > > know. I would suggest to drop it for the time being, and have one of the > > maintainers press the button manually. > > > > And although this is not a blocker IMO, I think we should spend some time > > writing a new GitHub "workflow" to mimic the "merge when CI passes" > > functionality. Maybe some plugins already exist to support this. > > Might https://github.com/apps/mergewhenready be useful? Quite likely. That's something that came up in my searches as well. I don't have first-hand experience of using this myself but we'll learn as we go along I guess :) > What about the merge method? On GitLab we use 'Merge commit with semi- > linear history'. Does GitHub support this already? Good question! I think the answer is yes. Although this functionality comes in form of two different knobs in GitHub that we can tweak: 1. When we set up branch protection rules, we will have to mark certain status checks as required (presumably all the current pre-merge checks). While doing so, we can enable the "Require branches to be up to date before merging" checkbox. This will give us the semi-linear part. 2. About the merge method itself, we have a choice between "merge", "squash & merge" and "rebase & merge". Assuming we enable the above check, the "merge" strategy would be equivalent to what we're doing now. Cheers, Chandan
