Packages は、コンテナーやその他の依存関係を含むパッケージをホストおよび管理するためのプラットフォームです。 Packages を使うと、ソース コードとパッケージを 1 か所にまとめ、統合されたアクセス許可管理と支払いを利用し、 上でのソフトウェア開発を一元化することができます。
Packages を の API、 Actions、Webhook と統合し、コード、CI、配置ソリューションを含むエンドツーエンドの DevOps ワークフローを作成できます。
Packagesは、nmp、RubyGems、Apache Maven、Gradle、Docker、NuGetといった、広く使われているパッケージマネージャーに対する様々なパッケージレジストリを提供しています。 の Container registry は、コンテナー向けに最適化されており、Docker と OCI イメージをサポートしています。 Packages がサポートしているさまざまなパッケージ レジストリの詳細については、「 Packagesレジストリの利用」を参照してください。
パッケージの README に加え、 に関するライセンス、ダウンロードの統計情報、バージョン履歴などを表示できます。 詳しくは、「パッケージの表示」をご覧ください。
パッケージのアクセス許可は、パッケージがホストされているリポジトリから継承されます。特定のユーザーや Organization 用に定義することもできます。 一部のレジストリでは、リポジトリから継承されたアクセス許可のみがサポートされます。 これらのレジストリの一覧については、「 Packagesの権限について」を参照してください。 パッケージ アクセスの詳細については、「パッケージのアクセス制御と可視性の設定」を参照してください。
パブリック リポジトリ (パブリック パッケージ) で パッケージを公開して、のすべてと共有できます。もしくはプライベート リポジトリ (プライベートパッケージ) でパッケージを公開して、コラボレーターあるいは Organization と共有できます。
Packagesの利用は、パブリックパッケージについては無料です。 プライベート パッケージについては、 の各アカウントは、一定量の無料のストレージとデータ転送を、そのアカウントのプランに応じて受け取ります。 含まれる量を超える使用は、使用制限によって制御されます。 月額料金のお客様の場合、既定のアカウントの料金の上限は 0 米国ドル (USD) になっており、含まれている量に達した後に追加でストレージやデータ転送が利用されないようになっています。 アカウントを請求書で支払っている場合、そのアカウントの既定の使用制限は無制限となります。詳細については、「About billing for Packages」を参照してください。
Packagesは、パッケージのバージョンの公開とインストールに、すでにおなじみのネイティブのパッケージツールコマンドを使います。
| Language | 説明 | パッケージの形式 | パッケージ クライアント |
|---|---|---|---|
| JavaScript | Nodeのパッケージマネージャー | package.json | npm |
| Ruby | RubyGemsパッケージマネージャー | Gemfile | gem |
| Java | Apache Mavenのプロジェクト管理及び包括的ツール | pom.xml | mvn |
| Java | Java用のGradleビルド自動化ツール | build.gradle または build.gradle.kts | gradle |
| .NET | .NET用のNuGetパッケージ管理 | nupkg | dotnet CLI |
| 該当なし | Dockerコンテナ管理プラットフォーム | Dockerfile | Docker |
メモ
Apache Maven レジストリと Gradle レジストリは、データ所在地付き Enterprise Cloud 用には使用できません。
Packages で使うパッケージ クライアントの構成の詳細については、「 Packagesレジストリの利用」を参照してください。
Docker と Container registry の詳細については、「コンテナレジストリの利用」を参照してください。
メモ
Packages では、personal access token (classic)を使用した認証のみがサポートされています。 詳しくは、「個人用アクセス トークンを管理する」をご覧ください。
非公開パッケージ、内部パッケージ、公開パッケージを発行、インストール、削除するには、アクセス トークンが必要です。
Packages、あるいは API で認証を受けるのに、personal access token (classic) を利用できます。 personal access token (classic) を作成するときは、必要に応じてさまざまなスコープをトークンに割り当てることができます。 personal access token (classic) のパッケージ関連のスコープについては、「 Packagesの権限について」を参照してください。
Actionsワークフロー内で Packagesレジストリに認証を受けるには、以下の方法が使えます。
_TOKENでは、ワークフロー リポジトリに関連付けられているパッケージを発行します。- 他のプライベート リポジトリに関連付けられたパッケージをインストールするために、少なくとも
read:packagesスコープが設定された personal access token (classic) (リポジトリにパッケージへの読み取りアクセス権が付与されている場合は、_TOKENを使用できます)。 「パッケージのアクセス制御と可視性の設定」を参照してください)。
Actions ワークフローで使われる _TOKEN の詳細については、「自動トークン認証」を参照してください。
パッケージは、 ユーザー インターフェイスまたは REST API を使って削除できます。 詳細については、「パッケージを削除および復元する」と「パッケージの REST API エンドポイント」を参照してください。 特定のレジストリでは、GraphQL を使ってプライベート パッケージのバージョンを削除できます。
詳細なアクセス許可をサポートするレジストリでは、 Packages GraphQL API を使用できません。 リポジトリ スコープのアクセス許可のみをサポートし、GraphQL API で使用できるレジストリについては、「 Packagesの権限について」をご覧ください。
GraphQL API を使ってプライベート パッケージに対するクエリや削除を行う場合、 Packages の認証に使うのと同じ personal access token (classic) を使わなければなりません。
詳細については、「GraphQLでの呼び出しの作成」を参照してください。
webhookを設定して、パッケージの公開や更新といったパッケージ関連のイベントにサブスクライブできます。 詳細については、「Webhook のイベントとペイロード」を参照してください。
Packages に対するフィードバックや機能の要求がある場合は、 Community ディスカッションをお使いください。
次の場合は、 Packages については Support ポータル からお問い合わせください。
- ドキュメンテーションに反する何らかの体験をした時
- 漠然とした、あるいは不明確なエラーを体験した時
- GDPR違反、APIキー、個人を識別する情報といったセンシティブなデータを含むパッケージを公開した時