ライブラリを開発してオープンソースにして、npmやCocoaPodsといった場所へパッケージとして公開することはよくあることだと思います。それを業務とかチームで使うこともよくあります。

そういった事をしてた時に、後から権限を付与しようとしたりリポジトリの管理で問題が出てくることがあったので、それについてのメモです。

この記事は、既に個人のアカウントで公開していたライブラリを後からどうやって権限の移譲や分配をしていくかという趣旨の内容です。

最初からチーム用のアカウントでやるのが正解な気がするので、そういうのとはちょっと違う方向かもしれません。

概要

3行で

  • 個人でオープンソースのライブラリ公開してた
  • 後になってチームで更新出来るようにしたくなった
  • そもそもライブラリとリポジトリで権限が別で何か面倒だね

CocoaPodsの例

SwiftとObjective-Cのパッケージ管理ツールであるCocoaPodsを例にしてみます。 CocoaPodsはRubyGemsやnpmと同じように、パッケージをpublishして公開する形なので、CocoaPodsを公開する用のアカウントがリポジトリとは別に必要です。

なので、パッケージはパッケージで権限を付与する必要があります。

登録済みのpodspecの取得

その人が登録しているCocoaPodsのパッケージを確認する

$ pod trunk me
  - Name:     azu
  - Email:    [email protected]
  - Since:    May 20th, 06:52
  - Pods:
    - UITextSubClass
    - MochaAsyncTest
    - SimpleUserDefaults
    - AZEncodeURIComponent
    - NSDictionaryAsURLQuery
    - UIImage-Teeny
    - RoleTabBarController
    - SnoozeLocalNotification
    - UIAlertView-NSErrorAddition
    - EasyMailSender
    - OpenFileInWebView
    - isUnitTesting
    - UITextFieldWithLimit
    - iOSDetector
    - XCTestCase+RunAsync
    - NSDate-Escort
    - CrayWebViewController
    - XCTestCase-RunAsync
    - ErrorGen
    - RequestInMemory
    - AZNSDateKiwiMatcher
    - LupinusHTTP
    - BlockValueTransformer
    - ManagedMappingObject
    - TimeRange
    - OperationPromise
    - AppStoreOpener
    - BlobURLOfUIImage
    - DrowningGraphicer
    - AZDateBuilder
    - SimplePanel
    - StoryboardInitializer
    - XUIRoundedRectButton
    - ArsDashFunction
    - CounterAgent
    - AppVersioning
    - OPBitMaskNumber
    - ArsScale

もしくはCocoaPods.orgで検索するなど。

権限の付与

一覧が確認できたら、公開の権限を付与したい人のCocoaPodsアカウントへ権限を与える。

取得したリストから余計なものを取り除いて

AppVersioning
OPBitMaskNumber
ArsScale

という感じの登録してるpod名のデータをクリップボードに入れておいて、pod trunk add-ownerで権限を付与する。

pbpaste | xargs -I% pod trunk add-owner "%" "付与するメールアドレス"

という感じでまとめて付与できる。

コマンドの詳細は以下に書かれています。

npmとかでもパッケージ毎に管理出来るユーザ(npmアカウント)を追加できるので同じですね。

GitHubリポジトリの移譲

GitHubでリポジトリを公開してる場合に、そのリポジトリもチームで共有しやすい形にしたいと思います。

GitHubの場合は方法がいくつかあると思います。

  • リポジトリのcollaboratorsに加える
    • 現状維持的なアプローチ
    • Collaborators権限でコミットも可能
    • OrganizationをCollaboratorsに追加はできない(=>移譲するしかない)
    • Collaboratorsがたくさんいる場合は組織アカウントへ移譲した方がいい
  • Organizationアカウントを作ってそこへリポジトリを移譲する
    • GitHubがリダイレクトしてくれるので最低限はそのまま維持される
    • URLが変わるので関連サービスなどが追従できない可能性はあるけど、リダイレクトされるので大抵は動く
    • READMEやpackage.jsonやpodspecのような関連ファイルを順次書き換えていく必要がある
  • 引き継ぐ人がforkして管理する
    • 積極的なメリットはない
    • リポジトリが分散する問題

リポジトリを移譲していくのが今後としてはいい気がしますが色々書き換えが面倒だったり、APIがないので自動化しにくかったりするので、必要に応じてやっていくのがいい気がします。

パッケージとリポジトリの権限が別である問題

今回は既に個人で公開していたものをチームで共有して更新しやすくするようにするという感じでしたが、やっぱりパッケージとリポジトリの権限が別だったり、リポジトリも移譲が面倒だったりします。

この辺は普通のオープンソースプロジェクトでも良く問題になる気がするので、リポジトリとパッケージ管理の権限が別れてる問題は何かいい方法があるといいなーという感じがします。

Golangなどリポジトリをそのまま指定するタイプはパッケージとリポジトリの権限がそのまま結びつくので、この問題はなさそうですがどうなんだろ?