kWatanabe 記事一覧へ

kWatanabe の 技術帖

某企業でOSや仮想化の研究をやっているインフラ系エンジニア。オンプレとクラウドのコラボレーションなど、興味ある技術を綴る。

ローカルのGitBucketをGitHubに移行する(その3)

  • ローカルサーバのGitBucketで管理していたリポジトリGitHubに移行したい
  • 過去記事では、リポジトリの移行と、Issue と Pull Request のダンプを行った
  • 今回は、GitBacket からダンプした Issue と Pull Request を GitHub に投稿する
  • なお、既に close され branch が消えていた Pull Requset は登録できないので、他のIssueやPull Requestの番号に齟齬が生じないように調整するにとどめる

その1とその2はこちら。

kwatanabe.hatenablog.jp

kwatanabe.hatenablog.jp

背景

過去記事参照。

GitHubAPI

Issue と Pull Request を作って閉じるために必要なAPIは以下の通り。

Issue の投稿

GitHub で Issue を作るときは、 Create an issueAPI をコールする。

developer.github.com

パラメータは以下の通り。残念ながら、MileStone との対応づけはない。

コール先:POST /repos/:owner/:repo/issues

パラメータ 概要 GitBucketからダンプしたモノとの対応
title string Issueのタイトル issue['titile']
body string 本文 issue['body']
milestone integer マイルストン番号 なし
labels array of strings ラベル名 issue['labels'][N]['name']
assignees array of strings アサイン先 issue['assignees'][N]['login']

Issue へのコメントの投稿

作った Issue にコメントする場合は、 Create an issue commentAPI をコールする。

developer.github.com

コール先:POST /repos/:owner/:repo/issues/:issue_number/comments

パラメータは以下の通り。issue_comments は、issuecomment_url に格納されているURLから、更にAPIをコールして取得したもの。その2 では、ダンプした issue の中に comments という key を追加して埋め込んでいる。

パラメータ 概要 GitBucketからダンプしたモノとの対応
body string コメント本文 issue_comments[N]['body']

Issue のクローズ

Issue をクローズする場合は、Update an issueAPI をコールする。

developer.github.com

コール先:PATCH /repos/:owner/:repo/issues/:issue_number

パラメータは以下の通り。クローズしたいだけなら、state だけ送ればいい。

パラメータ 概要 GitBucketからダンプしたモノとの対応
title string Issueのタイトル issue['titile']
body string 本文 issue['body']
milestone integer マイルストン番号 なし
labels array of strings ラベル名 issue['labels'][N]['name']
assignees array of strings アサイン先 issue['assignees'][N]['login']
state string openclosed issue['state']

Pull Request の投稿

Pull Request を作るときは、 Create a pull requestAPI をコールする。

コール先:POST /repos/:owner/:repo/pulls

developer.github.com

パラメータは以下の通り。

パラメータ 概要 GitBucketからダンプしたモノとの対応
title string タイトル pull['title']
body string 本文 pull['body']
head string 改修後のブランチ名 pull['head']['ref']
base string 改修前のブランチ名 pull['base']['ref']
draft boolean Draft Pull Requestか pull['draft']

Pull Request へのコメントの投稿

Pull Request にコメントを投稿するときは、Issue の時と同様に Create an issue commentAPI をコールする。

Pull Request のマージ

Pull Request をマージするときは、 Merge a pull requestAPI をコールする。

コール先:PUT /repos/:owner/:repo/pulls/:pull_number/merge

developer.github.com

パラメータは以下の通り。ただマージしたいだけなら sha だけ合わせておけばいい。

パラメータ 概要 GitBucketからダンプしたモノとの対応
commit_title string コミットメッセージのタイトル -
commit_message string コミットメッセージ -
sha string Pull RequestのheadのSHA pull['head']['sha']
merge_method string マージする方法 -

Pull Request のクローズ

Pull Request をクローズする場合は、Update a pull requestAPI をコールする。

developer.github.com

コール先:PATCH /repos/:owner/:repo/pulls/:pull_number

パラメータは以下の通り。クローズしたいだけなら、state だけ送ればいい。

パラメータ 概要 GitBucketからダンプしたモノとの対応
title string タイトル pull['title']
body string 本文 pull['body']
base string 改修前のブランチ名 pull['base']['ref']
draft boolean Draft Pull Requestか pull['draft']
state string openclosed pull['state']

手順

これらAPIを用いてGitHubに Issue と Pull Request を移行する。

アクセストークンを発行する

その1で移行したリポジトリに、その2でダンプした Issue を投稿する。

GitHubでもGitBucketの時と同じように、アクセストークンを発行する。

  1. GitHubにログインする
  2. アカウントのマイページにアクセスして
  3. Settings を選択
  4. Personal access tokens を選択
  5. Generate new token を選択
  6. Note にテキトーな名前を入れて
  7. repo にチェックをして
  8. Generation Token を選択する

するとアクセストークンが発行されるので、メモしておく。

f:id:kWatanabe:20201011220840p:plain
GitHubのアクセストーク

ダンプした Issue と Pull Request を登録する

注意点は以下の通り。

  • Issue 番号 と Pull Request 番号は同じ採番体系になっており、これらは投稿した順に採番される。そのため、元のIssue番号、Pull Request番号の通りに投稿する。
  • GitBucket で使っていたユーザ名が、GitHub でも使えるとは限らない。Issue の assignees には GitHub に存在するユーザ名に置換した上で投稿する。
  • クローズ済みの Pull Request について、Marge した後、リポジトリから head となる Branch が削除されていたりすると投稿できなくなる。私のリポジトリの場合、クローズ済みの Pull Request にあまり価値はない*1ので、ダミーの Issue を投稿して番号をずらして回避する。

特に工夫点はなく、愚直に API をコールし続ける。その2で作ったコードとマージして完成。

実際のコード

長くなったので、GitHubに公開します。

github.com

結果

  • GitBacket 上の Issue と open な Pull Request は Issue 番号やコメントの内容も含めて移行できた。
  • クローズした Pull Request はダミーIssue として移行した。
  • これで、ローカルのGitBucketのGitHubへの移行は完了となった。

*1:一方で、クローズされていても検討の課程が記録されている Issue は、ある意味リポジトリ本体よりも大切。