テクノロジー部門セキュリティ本部の清水です。セキュリティとは直接関係のない内容ですが、最近、あるOrganizationにあるリポジトリを別Organizationに移動させる作業を経験しました。今回は、その作業を通して得た知見を共有したいと思います。
リポジトリを別Organizationに移動させる作業をする時の参考となれば幸いです。
リポジトリの移動方法
GitHubでは、リポジトリを別Organizationへ移動させる方法を記述した公式のドキュメントが用意されています。やり方や注意事項が記載されているので、移動を実施する前に目を通しておくことをおすすめします。
公式ドキュメントの手順通りに進めれば、別Organizationへのリポジトリ移動を簡単に実施できます。また、公式ドキュメントには、どんな内容がリポジトリと一緒に移動されるかも記載されているので、移動作業を始める前に合わせて確認しましょう。以下のように対応しなくてもよしなに動くところもあります。
- ソースコードやIssueへのURLは、移動先に自動的にリダイレクトされるようになる。
- 移動先のOrganizationにもアカウントがあれば、Issueのassigneeは残る。
この記事では公式ドキュメントではあまり触れられていないけど、注意すると良いポイントを紹介していきたいと思います。
移動時に注意すると良いポイント
SlackとGitHubの連携
SlackとGitHubを連携して、GitHubのIssueが更新されたらSlackの特定チャネルで通知を受ける設定をしている開発チームは多いと思います（連携方法は、GitHub + Slack Integrationをご覧ください）。
リポジトリの移動作業をした際に、作業後にGitHubのIssueを更新しても通知を受けられない現象に遭遇しました。この現象は、 /github subscribe <organization>/<repository> の再実行で解決しました。（ちなみに、 /github subscribe <organization>/<repository> を1度だけ実行すると何故か通知が2回来るようになったため、さらにもう1度を実行すると正しく1回のみ通知を受けられるようになりました。）
Organizationに紐づくProject Board
多くの開発チームがGitHubのプロジェクトボード機能（カンバンと呼んでいる開発チームも多いかも？）を利用して、開発の進捗を管理していると思います。
プロジェクトボードには、リポジトリに紐づくタイプ（Repository project boards）とOrganization（Organization-wide project boards）に紐づくタイプがあります（ユーザに紐づくタイプもありますが本記事では省略）。
リポジトリに紐づくタイプのプロジェクトボードでは、別Organizationにリポジトリを移動させたとき、プロジェクトボードに紐づくIssueもリポジトリと一緒に移動するので紐付けに関する問題は特に発生しません。一方で、Organizationに紐づくタイプのプロジェクトボードの場合、プロジェクトボードは移動前のOrganizationに残されるので、プロジェクトボードとIssueの結びつきが切れてしまいます。
このため、Organizationに紐づくタイプのプロジェクトボードで、開発進捗を管理している場合、移動先のOrganizationにはそれまで利用していたプロジェクトボードが無く、移動前のOrganizationではプロジェクトボードの一部の Issueが抜け落ちた状態となる可能性があります。
普段利用しているプロジェクトボードは、リポジトリに紐づくタイプなのか Organizationに紐づくタイプなのかを確認して、Organizationに紐づくプロジェクトボードの場合はどんな影響が出そうか移動前に確認しましょう。
また、プロジェクトボードを作るときに特定のリポジトリのIssueしか取り扱わないのであれば、リポジトリに紐づくタイプでプロジェクトボードを作成しておけば移動時の紐付き問題は無くなります。プロジェクトボードの作成時には、どのタイプでプロジェクトボードを作成するべきか意識すると良いと思います。
リポジトリのアクセス権限
企業のソースコードを管理するリポジトリは、通常はプライベート設定にしていて、必要な開発者のみにリポジトリの閲覧や書き込み権限を付与するように権限を絞り込んでいます。しかし、リポジトリを別Organizationに移動すると、それまで設定していたパーミッション設定が失われる可能性があります。
例えば、移動前のOrganizationに所属していたアカウントAが、移動後のOrganizationに所属していない場合は、アカウントAは移動後のリポジトリにアクセス出来ないようになります。一方で、アカウントBが移動前後のOrganization両方に所属している場合は、アカウントBは移動後もリポジトリへのアクセス権を維持できます。 また、移動後のOrganizationにGitHubアカウントが存在していても、チーム単位でリポジトリへのアクセス権を管理している場合は、移動後のOrganizationに移動前のチームが存在しないためアクセス権は失われます。必要であれば、移動後のOrganizationで移動前のOrganizationと同じ内容のチームを作成して、リポジトリのアクセス権に紐付けるようにします。
リポジトリの別Organizationへの移動後も、必要な人に必要なリポジトリのアクセス権限が付与されるように、アクセス権限がどう変わるか事前に確認しておきましょう。
GitHubと連携したCI/CDタスク
GitHub ActionsなどのCI/CDツールを利用している開発チームは多いと思います。リポジトリを別Organizationに移動させることによって、CI/CDの動作に問題の生じる場合があるので、その影響を事前に確認する必要があります。 今回の移動作業では、移動前のOrganizationに対して特定の検索条件でIssueの一覧を取得するCI/CDタスクがあり、リポジトリを移動させることでそのリポジトリに紐づくIssueも移動して、検索結果が変わってしまうことがわかりました。タスクの動作に影響が出るため、事前に修正の対応を行いました。
まとめ
以上、リポジトリを移動させる時に注意すると良いポイントを紹介しました。公式ドキュメントと併せて、本記事で記載した注意ポイントに気をつけてリポジトリを無事に別Organizationに移動させてください。
