Uzzu::Blog

Software Design, and my life.

GitHub上でのGradle Projectの管理状況2021

JCenter/Bintrayが追々シャットダウンするとの事で、なかなか大変な状況です。 わたしの作っているライブラリはというとちょうど去年Maven Centralに全部移行したところでした。 あとは依存ライブラリの確認をしなければとかこまい所が残っています。 せっかく整理したのに文書化してなかったので、文書化しておこうと思います。

Maven CentralへのMaven Artifact Groupの登録

Maven Central へのArtifactの登録ははなんだか難しいと思われがちですが、案内に従えばシュッと対応してもらえるので、あんまり構える必要はないです。 強いていえば、自身のドメインを持っておき、Artifact Group名もドメインに合わせおくのが一番楽です。

New Project Ticketを作成してそのまましばらく何もアクションをせずに放置していると、「このArtifact Groupの情報を参照できるページ(GitHubならGitHub Pages のURL)をコメントするか、このTicketのリンクのURLをTXTレコードに登録してください」と言われます。

ドキュメント整備をやるほど気概のあるプロジェクトならまだしも、まだ作ってる最中のものの GitHub Pages を用意するというのはなかなか大変だと思います。 なので、TXTレコードを登録する方法が手っ取早い。

  • 事前準備として、Artifact Group名と同じドメインを取得しておく
    • 例: uzzu.co
  • Artifact Group 名が取得したドメインのサブドメインとなるような Artifact Group を作成するよう New Project Ticket を作成する
    • 例: co.uzzu.hogehoge
  • 返答を待たずして、ドメインの DNS 設定からTXTレコードとしてTicketのURLを登録する

としておくと、 (定期的に sonartype が nslookup でも実行しているんでしょうけど) 10分程度でArtifact Groupの作成が承認され、Maven Central Repositoryへのアップロードの案内がコメントされます。 煩わしいやり取りも一切ないので、これが一番手間がかからないんじゃないかなと思います。持つべきものはドメイン。

OSSRHでは他人のNew Project Ticketも見れるので参考にすると良いでしょう。よければ自分のTicketも参考にしてください。 https://issues.sonatype.org/browse/OSSRH-60456 Ticket作成と、初回リリース時のArtifactのアップロード報告以外は何もしてないのが分かると思います。

Maven CentralでのMaven Artifactの配布に必要なものの準備

snapshot repositoryではなく本番のMaven CentralでArtifactを配布する際には、JavaDoc ArtifactとArtifactのPGP Signingが必要です。

JavaDoc Artifactについては含まれてさえいれば空のjarファイルでも良さそうな気がしています。試してないのでわからない。 わたしは全てKotlin Projectなのでdokkaを使ってみてますが、特に人に見せられるようなほど内容も詰まってないし、中身のチェックはされてなさそう。

  • Java Projectの場合
  • Kotlin Multiplatform Projectの場合
    • こんなかんじ1
    • こんなかんじ2
    • 微妙にJava Projectと記述が違うけど、やってる事は変わんないので大目に見てほしい
    • dokkaやKotlin Pluginのバージョンで記述は変わるのでその辺も一応念頭においた上で参考にどうぞ

PGP Signingそのものの説明についてはインターネット上にたくさん記事があるので割愛します。 Gradle Script上でのPGP SigningはGradle標準で Signing Pluginがあるのでこれを利用します。

加えて、Gradle 5.4から(まだstatusとしては @Incubating ですが) useInMemoryPgpKeys を用いる事で ascii-armored OpenPGP keys/subkeys が取り扱えるようになっているので、これを使っています。 あとはドッグフーディングも兼ねて自作のDotEnv Gradle Plugin を使って以下のように記述しています。

env.HOGEHOGE ってなんぞやってなった方はDotEnv Pluginを作ったときの記事があるのでそっちを読んでください。

Maven Centralへのアップロード

maven-publish を使っています。mavenDeployerやその他様々Publish Pluginがありましたが、Gradle標準の maven-publish に戻ってきました。

  • Java Projectの場合
  • Kotlin Multiplatform Projectの場合
    • こんなかんじ
    • Kotlin Pluginのバージョンで記述は変わるのでその辺も一応念頭においた上で参考にどうぞ。1.4.20 からcommon artifactの -metadata suffixがなくなったはずなのでそれに対応する必要がありそう

ただし、実際にMaven Centralでの配布に利用するMaven Repositoryへのアップロードを行う際に maven-publish だけでやる場合は、./gradlew publish したあとにアップロード先の管理ツールのNexus Repository Managerにいってポチポチする必要があります。この辺もサボりたい方にはgradle-nexus-staging-pluginを使うと、ポチポチ操作も自動でやってくれるのでそちらを使うと良いと思います。 自分が使っていないのは Artifact のアップロード確認をしていた名残りな所があります。

Maven Centralへのアップロードの半自動化

手元でアップロード作業の為の環境変数を持ちたくないので、必要な値はGitHub RepositoryのSecretsに突っ込んで、GitHub workflowのworkflow dispatchで手動トリガーでアップロードをしています。 自動リリースはしてません。

  • workflowはこんなかんじ
    • Maven Localに先にpublishしているのはGradle Scriptの記述ミスでArtifactの一部だけアップロード成功して途中で失敗してしまうケースを事前に検知する為にやっていたもので、今となっては特に意味がない

複数のGradle ProjectのSecretsの管理

GitHub Organizationを作成してそこにRepositoryを作成してしまえばSecretsを共有できるのですが、個人のRepositoryではよしなにやる必要があります。 そんな最中でGradle Projectが増えてくるとSecretsの管理が面倒になってきます。 そこで、Secrets管理用のRepositoryを作成し、そのRepositoryからgoogle/secrets-sync-actionを使って各RepositoryのSecretsを同期しています。 特に隠す必要もないんですが、実験中にうっかり秘匿値が公開されてしまったら怖いのでPrivate Repositoryでやっています。

そんな感じです。参考になれば幸いです。

comments powered by Disqus