Hi Chandan, Thanks for writing this up.
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. 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. > * 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 assume we won't delete the BuildStream project on GitLab and rather make it read-only/archive (with a link to GitHub), so it would be possible to find the MR title via the read-only GitLab project. However, it would be good if we didn't depend on this. We could likely also extract a table of GitLab MR number to title from a GitLab project export as a simple stopgap. > * 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? What about the merge method? On GitLab we use 'Merge commit with semi- linear history'. Does GitHub support this already? Cheers, Jürg
