Skip to main content

GitHub Actionsでのパッケージの公開とインストール

GitHub Actionsでのワークフローを、自動的にパッケージをに公開もしくはGitHub Packagesからインストールするように設定できます。

GitHub Packages は、GitHub Free、GitHub Pro、Organization の GitHub Free、GitHub Team、GitHub Enterprise Cloud、GitHub Enterprise Server 3.0 以降、GitHub AE で利用できます。
GitHub Packagesは、レガシーのリポジトリごとのプランを使っているアカウントが所有しているプライベートリポジトリでは利用できません。 また、レガシーのリポジトリごとのプランを使っているアカウントは、リポジトリごとに課金される Container registry にはアクセスできません。 詳細については、「GitHub's products」を参照してください。

GitHub ActionsとのGitHub Packagesについて

GitHub Actionsは、コードを保存するのと同じ場所でソフトウェア開発のワークフローを自動化し、プルリクエストやIssueで協力することを支援します。 個々のタスクを書き、アクションを呼び出し、それらを組み合わせてカスタムのワークフローを作成できます。 GitHub Actions では、エンドツーエンドの継続的インテグレーション (CI) と継続的デプロイメント (CD) 機能をリポジトリに直接ビルドすることができます。 詳しい情報については「GitHub Actions について」を参照してください。

ワークフローの一部としてパッケージの公開やインストールを行うことで、リポジトリのCI及びCDの機能を拡張できます。

Container registry and npm registry に対する認証

お使いのワークフローで個人アクセス トークン (PAT) を使用してレジストリの認証を受ける場合、GITHUB_TOKEN を使用するようにワークフローを更新することを強くお勧めします。

個人用アクセス トークンでレジストリの認証を行うワークフローの更新についてのガイダンスは、「PAT を使ってレジストリにアクセスするワークフローをアップグレードする」をご覧ください。

GITHUB_TOKEN の詳細については「ワークフローで認証する」を参照してください。

アクションでレジストリを使用するときのベスト プラクティスについて詳しくは「GitHub Actions のセキュリティ強化」をご覧ください。

GitHub 上のパッケージレジストリを認証する

ワークフローが GitHub Packages に対して認証されるようにして、GitHub.com 上の Container registry 以外のパッケージ レジストリにアクセスできるようにしたい場合は、、認証用の個人用アクセス トークンではなく、GitHub Actions を有効化する際に GitHub Enterprise Cloud でリポジトリに対して自動的に作成される、GITHUB_TOKEN を使用することをお勧めします。 ワークフロー ファイルでこのアクセス トークンにアクセス許可を設定して、contents スコープに対する読み取りアクセス権と、packages スコープに対する書き込みアクセス権を付与する必要があります。 フォークの場合、GITHUB_TOKEN には親リポジトリの読み取りアクセス権が付与されます。 詳細については、「GITHUB_TOKEN を使用した認証」を参照してください。

ワークフロー ファイル内の GITHUB_TOKEN は、{{secrets.GITHUB_TOKEN}} コンテキストを使って参照できます。 詳細については、「GITHUB_TOKEN を使用した認証」を参照してください。

リポジトリが所有するパッケージに対する権限とパッケージアクセスについて

注: RubyGems、Apache Maven、NuGet、、Gradleなどの一部のレジストリでは、レポジトリ所有のパッケージのみが許可されます。 Container registry (ghcr.io) and npm registry (npm.pkg.github.com) を使用すると、ユーザーまたは Organization がパッケージを所有できるようにするか、リポジトリにリンクできるようにするかを選択できます。

GitHub Actionsを有効化すると、GitHubはリポジトリにGitHub Appをインストールします。 GITHUB_TOKEN シークレットは、GitHub App インストール アクセス トークンです。 このインストールアクセストークンは、リポジトリにインストールされたGitHub Appの代わりに認証を受けるために使うことができます。 このトークンの権限は、ワークフローを含むリポジトリに限定されます。 詳細については、「GITHUB_TOKEN のアクセス許可」を参照してください。

GitHub Packages を使用すると、GitHub Actions ワークフローで利用できる GITHUB_TOKEN を通じてパッケージをプッシュしたりプルしたりできます。

Container registry and npm registry の権限とパッケージ アクセスについて

Container registry (ghcr.io) and npm registry (npm.pkg.github.com) を使うと、ユーザーは Organization レベルの自立リソースとしてパッケージを作成し、管理できます。 Organization または個人アカウントがパッケージを所有でき、それぞれのパッケージへのアクセスはリポジトリ権限とは別にカスタマイズできます。

Container registry and npm registry にアクセスするすべてのワークフローは、個人用アクセス トークンではなく GITHUB_TOKEN を使う必要があります。 セキュリティのベスト プラクティスについて詳しくは、「GitHub Actions のセキュリティ強化」を参照してください。

ワークフローを通じて変更されたコンテナに対するデフォルトの権限及びアクセス設定

ワークフローを通じてコンテナを作成、インストール、変更、削除する場合、管理者がワークフローに確実にアクセスできるようにするために使われるデフォルトの権限及びアクセス設定があります。 これらのアクセス設定も調整できます。

たとえば既定では、ワークフローで GITHUB_TOKEN を使用してコンテナーが作成された場合:

  • コンテナはワークフローが実行されたリポジトリの可視性と権限モデルを継承します。
  • ワークフローが実行されたリポジトリの管理者は、コンテナが作成されるとそのコンテナの管理者になります。

パッケージを管理するワークフローに対してデフォルトの権限の働き方の例は、もっとあります。

GitHub Actionsワークフロータスク既定のアクセス許可とアクセス
既存のコンテナのダウンロード- コンテナがパブリックなら、任意のリポジトリで実行された任意のワークフローがコンテナをダウンロードできる。
- コンテナーがインターナルなら、エンタープライズ アカウントが所有する任意のリポジトリ内で実行されるすべてのワークフローがコンテナーをダウンロードできる。 エンタープライズが所有する組織の場合は、エンタープライズ内の任意のリポジトリを読み取ることができる
- コンテナーがプライベートなら、そのコンテナーへの読み取り権限を与えられているリポジトリ内で動作するワークフローのみが、そのコンテナーをダウンロードできる。
新しいバージョンの既存のコンテナへのアップロード- コンテナがプライベート、インターナル、パブリックなら、そのコンテナへの書き込み権限を与えられたリポジトリで動作するワークフローだけが新バージョンをそのコンテナにアップロードできる。
コンテナもしくはコンテナのバージョンの削除- コンテナがプライベート、インターナル、パブリックなら、削除権限を与えられたリポジトリ内で動作するワークフローのみがコンテナの既存のバージョンを削除できる。

コンテナへのアクセスをもっと詳細に調整したり、デフォルトの権限動作の一部を調整したりすることもできます。 詳しくは、「パッケージのアクセス制御と可視性の設定」を参照してください。

アクションを使ったパッケージの公開

継続的インテグレーション (CI) フローの一環として、GitHub Actionsを使用してパッケージを自動的に公開できます。 この継続的デプロイメント (CD) に対するアプローチにより、コードが品質基準を満たしている場合に新しいパッケージの作成を自動化できます。 たとえば、開発者が特定のブランチにプッシュするたびに CI テストを実行するワークフローを作成してはいかがでしょう。 テストにパスすると、このワークフローは新しいパッケージバージョンをGitHub Packagesに公開できます。

パッケージのクライアントによって、設定のステップは様々です。 GitHub Actions のワークフローの構成に関する一般的な情報については、「ワークフローの構成」を参照してください。

以下の例では、GitHub Actionsを使用してアプリケーションのビルドとテストを行い、それから自動的にDockerイメージを作成してGitHub Packagesに公開する方法を示しています。

リポジトリに新しいワークフロー ファイル (.github/workflows/deploy-image.yml など) を作成し、以下の YAML を追加します。

YAML
# このワークフローはGitHubによって認定されていないアクションを使用します。
# それらはサードパーティによって提供され、
# 別個の利用規約、プライバシーポリシー、
# ドキュメントを参照してください。

# GitHub では、コミット SHA にアクションをピン留めすることが推奨されます。
# 新しいバージョンを取得するには、SHA を更新する必要があります。
# タグまたはブランチを参照することもできますが、アクションは警告なしに変更される可能性があります。

name: Create and publish a Docker image

on:
 push:
   branches: ['release']

env:
 REGISTRY: ghcr.io
 IMAGE_NAME: ${{ github.repository }}

jobs:
 build-and-push-image:
   runs-on: ubuntu-latest
   permissions:
     contents: read
     packages: write

   steps:
     - name: Checkout repository
       uses: actions/checkout@v3

     - name: Log in to the Container registry
       uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9
       with:
         registry: ${{ env.REGISTRY }}
         username: ${{ github.actor }}
         password: ${{ secrets.GITHUB_TOKEN }}

     - name: Extract metadata (tags, labels) for Docker
       id: meta
       uses: docker/metadata-action@98669ae865ea3cffbcbaa878cf57c20bbf1c6c38
       with:
         images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}

     - name: Build and push Docker image
       uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc
       with:
         context: .
         push: true
         tags: ${{ steps.meta.outputs.tags }}
         labels: ${{ steps.meta.outputs.labels }}

上記に関連する設定については、次の表で説明しています。 ワークフロー内の各要素の詳細については、「GitHub Actions のワークフロー構文」を参照してください。

```yaml on: push: branches: ['release'] ``` release というブランチに変更をプッシュするたびに、Create and publish a Docker image ワークフローを実行するよう設定します。
env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}
ワークフローに2つのカスタムの環境変数を定義します。 これらはContainer registryドメイン、そしてこのワークフローがビルドするDockerイメージの名前として使われます。
jobs:
  build-and-push-image:
    runs-on: ubuntu-latest
このワークフロー中には1つのジョブがあります。 これは、Ubuntuの利用可能な最新バージョンで実行されるよう設定されています。
```yaml permissions: contents: read packages: write ``` GITHUB_TOKEN に付与されているアクセス許可をこのジョブ内のアクション用に設定します。
```yaml - name: Log in to the Container registry uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9 with: registry: ${{ env.REGISTRY }} username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} ``` パッケージを公開するアカウントとパスワードを使ってレジストリにログインする Log in to the Container registry というステップを作成します。 いったん公開されると、パッケージはここで定めたアカウントが所有することになります。
```yaml - name: Extract metadata (tags, labels) for Docker id: meta uses: docker/metadata-action@98669ae865ea3cffbcbaa878cf57c20bbf1c6c38 with: images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} ``` このステップは docker/metadata-action を使って、指定されたイメージに適用されるタグとラベルを抽出します。 id "meta"は、このステップの出力が以降のステップから参照できるようにします。 images の値は、タグとラベルのためのベース名を提供します。
```yaml - name: Build and push Docker image ``` Build and push Docker image という新しいステップを作成します。 このステップは、build-and-push-image ジョブの一部として実行されます。
```yaml uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc ``` Docker の build-push-action アクションを使用して、リポジトリの Dockerfile を元にイメージをビルドします。 ビルドが成功すると、イメージをGitHub Packagesにプッシュします。
```yaml with: ``` 必要なパラメーターを build-push-action アクションに送信します。 これらは以降の行で定義されます。
```yaml context: . ``` ビルドのコンテキストを、指定されたパス内にあるファイル群として定義します。 詳細については、「使用」を参照してください。
```yaml push: true ``` ビルドに成功したら、このイメージをレジストリにプッシュします。
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}
"meta"ステップで抽出されたタグとラベルを追加します。

この新しいワークフローは、リポジトリの release という名前のブランチに変更をプッシュするたびに自動的に実行されます。 [アクション] タブで、この進捗を表示できます。

ワークフローが完成すると、その数分後にリポジトリで新しいパッケージが表示されます。 使用可能なパッケージを見つけるには、「リポジトリのパッケージを表示する」を参照してください。

アクションを使ったパッケージのインストール

GitHub Actionsを使い、CIフローの一部としてパッケージをインストールできます。 たとえば、開発者がコードをプルリクエストにプッシュすると、いつでもワークフローがGitHub Packagesによってホストされているパッケージをダウンロードしてインストールすることで、依存関係を解決するようにワークフローを設定できます。 そして、ワークフローはその依存関係を必要とするCIテストを実行できます。

GitHub Actions を通じて GitHub Packages がホストするパッケージをインストールするには、GITHUB_TOKEN を使う際に最小限の設定もしくは追加の認証が必要です。アクションがパッケージをインストールする場合、データ転送も無料です。 詳細については、「GitHub Packages の課金について」を参照してください。

パッケージのクライアントによって、設定のステップは様々です。 GitHub Actions のワークフローの構成に関する一般的な情報については、「ワークフローの構成」を参照してください。

PAT を使用してレジストリにアクセスするワークフローのアップグレード

Container registry and npm registry は、ワークフロー内での、簡単でセキュリティで保護された認証のために GITHUB_TOKEN をサポートしています。 お使いのワークフローで個人アクセス トークン (PAT) を使用してレジストリの認証を受ける場合、GITHUB_TOKEN を使用するようにワークフローを更新することを強くお勧めします。

GITHUB_TOKEN の詳細については「ワークフローで認証する」を参照してください。

PAT の代わりに repo スコープを含む GITHUB_TOKEN を使えば、ワークフローが実行されるリポジトリへの不要なアクセスを提供する長期間有効な PAT を使う必要がなくなるので、リポジトリのセキュリティが向上します。 セキュリティのベスト プラクティスについて詳しくは、「GitHub Actions のセキュリティ強化」を参照してください。

  1. パッケージのランディングページにアクセスしてください。

  2. 左側のサイドバーで、 [アクションのアクセス] をクリックします。 左側のメニューの [アクションのアクセス] オプション

  3. コンテナパッケージがワークフローに確実にアクセスできるようにするためには、ワークフローが保存されているリポジトリをコンテナに追加しなければなりません。 [リポジトリの追加] をクリックして、追加するリポジトリを検索します。 [リポジトリの追加] ボタン

    注: [アクションのアクセス] メニュー オプションを使用してコンテナーにリポジトリを追加する操作は、コンテナーをリポジトリに接続する操作とは異なります。 詳細については、「パッケージへのワークフローのアクセスの確保」と「リポジトリのパッケージへの接続」を参照してください。

  4. あるいは"role(ロール)"ドロップダウンメニューを使い、コンテナイメージに対してリポジトリに持たせたいデフォルトのアクセスレベルを選択してください。 リポジトリに付与するアクセス レベル

  5. ワークフローファイルを開いてください。 レジストリへのログインの行で、お使いの PAT を ${{ secrets.GITHUB_TOKEN }} に置き換えてください。

たとえば、このワークフローでは、Docker イメージを Container registry に公開し、${{ secrets.GITHUB_TOKEN }} を使って認証します。

YAML
name: Demo Push

on:   
  push:
    # Publish `master` as Docker `latest` image.
    branches:
      - master
      - seed

    # Publish `v1.2.3` tags as releases.
    tags:
      - v*

  # Run tests for any PRs.
  pull_request:

env:
  IMAGE_NAME: ghtoken_product_demo

jobs:
  # Push image to GitHub Packages.
  # See also https://docs.docker.com/docker-hub/builds/
  push:
    runs-on: ubuntu-latest
    permissions:
      packages: write
      contents: read

    steps:
      - uses: actions/checkout@v3

      - name: Build image
        run: docker build . --file Dockerfile --tag $IMAGE_NAME --label "runnumber=${GITHUB_RUN_ID}"

      - name: Log in to registry
        # This is where you will update the PAT to GITHUB_TOKEN
        run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u $ --password-stdin

      - name: Push image
        run: |
          IMAGE_ID=ghcr.io/${{ github.repository_owner }}/$IMAGE_NAME

          # Change all uppercase to lowercase
          IMAGE_ID=$(echo $IMAGE_ID | tr '[A-Z]' '[a-z]')
          # Strip git ref prefix from version
          VERSION=$(echo "${{ github.ref }}" | sed -e 's,.*/\(.*\),\1,')
          # Strip "v" prefix from tag name
          [[ "${{ github.ref }}" == "refs/tags/"* ]] && VERSION=$(echo $VERSION | sed -e 's/^v//')
          # Use Docker `latest` tag convention
          [ "$VERSION" == "master" ] && VERSION=latest
          echo IMAGE_ID=$IMAGE_ID
          echo VERSION=$VERSION
          docker tag $IMAGE_NAME $IMAGE_ID:$VERSION
          docker push $IMAGE_ID:$VERSION