Публикация и установка пакета с помощью GitHub Actions

О своём GitHub PackagesGitHub Actions

GitHub Actions позволяет автоматизировать рабочие процессы разработки программного обеспечения в том же расположении, где вы храните код и совместно работаете над запросами на вытягивание и проблемами. Вы можете написать отдельные задачи (т. н. действия) и объединить их для создания пользовательского рабочего процесса. С помощью GitHub Actions можно создавать комплексные возможности непрерывной интеграции и непрерывного развертывания непосредственно в репозитории. Для получения дополнительной информации см. Написание рабочих процессов.

Вы можете расширить возможности CI и CD вашего репозитория, публикуя или устанавливая пакеты в рамках рабочего процесса.

Проверка подлинности в реестрах пакетов с подробными разрешениями

Некоторые GitHub Packages реестры поддерживают детализированные разрешения. Это означает, что вы можете разрешить пакеты быть ограничены пользователем или организацией или связаны с репозиторием. Список реестров, поддерживающих детализированные разрешения, см. в разделе Сведения о разрешениях для пакетов GitHub.

Для реестров, поддерживающих детализированные разрешения, если рабочий процесс GitHub Actions использует personal access token для проверки подлинности в реестре, настоятельно рекомендуется обновить рабочий процесс для использования GITHUB_TOKEN. Инструкции по обновлению рабочих процессов, прошедших проверку подлинности в реестре с помощью personal access token, см. в разделе Публикация и установка пакета с помощью GitHub Actions.

Вы можете использовать GITHUB_TOKEN рабочий процесс GitHub Actions для удаления или восстановления пакета с помощью REST API, если маркер имеет admin разрешение на пакет. Репозитории, публикующие пакеты с помощью рабочего процесса и репозиториев, которые явно подключены к пакетам, автоматически предоставляются admin разрешения на пакеты в репозитории.

Дополнительные сведения см. в GITHUB_TOKENразделе Использование GITHUB_TOKEN для проверки подлинности в рабочих процессах. Дополнительные сведения о рекомендациях при использовании реестра в действиях см. в разделе Справочник по безопасному использованию.

Проверка подлинности в реестрах пакетов с разрешениями на уровне репозитория

Некоторые GitHub Packages реестры поддерживают только разрешения в области репозитория и не поддерживают детализированные разрешения. Список этих реестров см. в разделе Сведения о разрешениях для пакетов GitHub.

Если вы хотите, чтобы рабочий GitHub Packages процесс мог получить доступ к реестру, который не поддерживает детализированные разрешения, рекомендуется использовать GITHUB_TOKEN автоматически GitHub создаваемый для репозитория при включении GitHub Actions. Вам следует установить разрешения для этого маркера доступа в файле рабочего процесса, чтобы предоставить доступ на чтение в области contents и доступ на запись в области packages. Для вилок GITHUB_TOKEN предоставляется доступ на чтение в родительском репозитории. Дополнительные сведения см. в разделе Использование GITHUB_TOKEN для проверки подлинности в рабочих процессах.

Вы можете ссылаться на GITHUB_TOKEN файл рабочего процесса с помощью контекста$. Дополнительные сведения см. в разделе Использование GITHUB_TOKEN для проверки подлинности в рабочих процессах.

Сведения о разрешениях и доступе к пакетам

Пакеты, ограниченные пользователями или организациями

Реестры, поддерживающие детализированные разрешения, позволяют пользователям создавать и администрировать пакеты как бесплатные ресурсы на уровне организации. Пакеты могут быть ограничены организацией или личная учетная запись, и вы можете настроить доступ к каждому из пакетов отдельно от разрешений репозитория.

Все рабочие процессы, обращающиеся к реестрам, поддерживающим детализированные разрешения, должны использовать GITHUB_TOKEN вместо него personal access token. Дополнительные сведения о рекомендациях по обеспечению безопасности см. в разделе Справочник по безопасному использованию.

Пакеты с областью действия в репозиториях

Когда вы включаете GitHub Actions, GitHub устанавливает приложение GitHub в вашем репозитории. Секрет GITHUB_TOKEN — это маркер доступа к установке приложения GitHub. Маркер доступа установки можно использовать для проверки подлинности от имени приложения GitHub, установленного в вашем репозитории. Разрешения маркера ограничены репозиторием, содержащим рабочий процесс. Дополнительные сведения см. в разделе Использование GITHUB_TOKEN для проверки подлинности в рабочих процессах.

GitHub Packages позволяет отправлять и извлекать пакеты через доступный GITHUB_TOKEN рабочий GitHub Actions процесс.

Разрешения и параметры доступа по умолчанию для пакетов, измененных с помощью рабочих процессов

Для пакетов в реестрах, поддерживающих детализированные разрешения, при создании, установке, изменении или удалении пакета через рабочий процесс существуют некоторые параметры разрешений и доступа по умолчанию, используемые для обеспечения доступа администраторов к рабочему процессу. Вы также можете настраивать эти параметры доступа. Список реестров, поддерживающих детализированные разрешения, см. в разделе Сведения о разрешениях для пакетов GitHub.

Например, по умолчанию, если рабочий процесс создает пакет с помощью GITHUB_TOKEN, то:

• Пакет наследует модель видимости и разрешений репозитория, где выполняется рабочий процесс.
• Администраторы репозитория, на которых выполняется рабочий процесс, становятся администраторами пакета после создания пакета.

Ниже приведены дополнительные примеры работы разрешений по умолчанию для рабочих процессов, управляющих пакетами.

Вы также можете настроить доступ к пакетам более детально или настроить некоторые действия разрешений по умолчанию. Дополнительные сведения см. в разделе Настройка управления доступом и видимости пакета.

Публикация пакета с помощью действия

Вы можете использовать GitHub Actions для автоматической публикации пакетов в рамках потока непрерывной интеграции (CI). Такой подход к непрерывному развертыванию (CD) позволяет автоматизировать создание новых версий пакетов, если код соответствует вашим стандартам качества. Например, можно создать рабочий процесс, который выполняет тесты CI каждый раз, когда разработчик отправляет код в определенную ветвь. Если тесты проходят, рабочий процесс может опубликовать новую версию GitHub Packagesпакета в .

Действия по настройке зависят от клиента пакета. Общие сведения о настройке рабочего процесса для GitHub Actionsсм. в разделе Написание рабочих процессов.

В следующем примере показано, как можно использовать GitHub Actions для сборки и тестирования приложения, а затем автоматически создать образ Docker и опубликовать его GitHub Packagesв. Соответствующие параметры описаны в коде. Полные сведения о каждом элементе рабочего процесса см. в разделе Синтаксис рабочего процесса для GitHub Actions.

Создайте новый файл рабочего процесса в репозитории (например .github/workflows/deploy-image.yml, и добавьте следующий YAML).

#
name: Create and publish a Docker image

# Configures this workflow to run every time a change is pushed to the branch called `release`.
on:
  push:
    branches: ['release']

jobs:
# This job checks out the repository contents, installs `npm`, uses npm and webpack to build the app, and uploads the built files as an artifact that can be downloaded later in the workflow.
# It assumes that the built files are written to a directory called `public`.
  run-npm-build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - name: npm install and build webpack
        run: |
          npm install
          npm run build
      - uses: actions/upload-artifact@v3
        with:
          name: webpack artifacts
          path: public/

# This job uses `npm test` to test the code. `needs: run-npm-build` makes this job dependent on the `run-npm-build` job.
  run-npm-test:
    runs-on: ubuntu-latest
    needs: run-npm-build
    strategy:
      matrix:
        os: [ubuntu-latest]
        node-version: [14.x, 16.x]
    steps:
      - uses: actions/checkout@v6
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - uses: actions/download-artifact@v3
        with:
          name: webpack artifacts
          path: public
      - name: npm install, and test
        run: |
          npm install
          npm test
        env:
          CI: true

# This job publishes the package. `needs: run-npm-test` makes this job dependent on the `run-npm-test` job.
  build-and-push-image:
    runs-on: ubuntu-latest
    needs: run-npm-test 
    # Sets the permissions granted to the `GITHUB_TOKEN` for the actions in this job.
    permissions:
      contents: read
      packages: write 
      #
    steps:
      - name: Checkout
        uses: actions/checkout@v6
      # Uses the `docker/login-action` action to log in to the registry using the account and password that will publish the packages. Once published, the packages are scoped to the account defined here.
      - name: Log in to GitHub Docker Registry
        uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1
        with:
          registry: docker.pkg.github.com
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      # This step uses the `docker/build-push-action` action to build the image, based on your repository's `Dockerfile`. If the build succeeds, it pushes the image to GitHub Packages.
      # It uses the `tags` parameter to tag the image with the SHA of the commit that triggered the workflow.
      - name: Build and push Docker image
        uses: docker/build-push-action@f2a1d5e99d037542a71f64918e516c093c6f3fc4
        with:
          push: true
          tags: |
            docker.pkg.github.com/${{ github.repository }}/octo-image:${{ github.sha }}

name: Create and publish a Docker image

on:
  push:
    branches: ['release']
jobs:

  run-npm-build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - name: npm install and build webpack
        run: |
          npm install
          npm run build
      - uses: actions/upload-artifact@v3
        with:
          name: webpack artifacts
          path: public/

  run-npm-test:
    runs-on: ubuntu-latest
    needs: run-npm-build
    strategy:
      matrix:
        os: [ubuntu-latest]
        node-version: [14.x, 16.x]
    steps:
      - uses: actions/checkout@v6
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - uses: actions/download-artifact@v3
        with:
          name: webpack artifacts
          path: public
      - name: npm install, and test
        run: |
          npm install
          npm test
        env:
          CI: true

  build-and-push-image:
    runs-on: ubuntu-latest
    needs: run-npm-test 

    permissions:
      contents: read
      packages: write 

    steps:
      - name: Checkout
        uses: actions/checkout@v6

      - name: Log in to GitHub Docker Registry
        uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1
        with:
          registry: docker.pkg.github.com
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push Docker image
        uses: docker/build-push-action@f2a1d5e99d037542a71f64918e516c093c6f3fc4
        with:
          push: true
          tags: |
            docker.pkg.github.com/${{ github.repository }}/octo-image:${{ github.sha }}

#
name: Create and publish a Docker image

# Configures this workflow to run every time a change is pushed to the branch called `release`.
on:
  push:
    branches: ['release']

jobs:
# This job checks out the repository contents, installs `npm`, uses npm and webpack to build the app, and uploads the built files as an artifact that can be downloaded later in the workflow.
# It assumes that the built files are written to a directory called `public`.
  run-npm-build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - name: npm install and build webpack
        run: |
          npm install
          npm run build
      - uses: actions/upload-artifact@v3
        with:
          name: webpack artifacts
          path: public/

# This job uses `npm test` to test the code. `needs: run-npm-build` makes this job dependent on the `run-npm-build` job.
  run-npm-test:
    runs-on: ubuntu-latest
    needs: run-npm-build
    strategy:
      matrix:
        os: [ubuntu-latest]
        node-version: [14.x, 16.x]
    steps:
      - uses: actions/checkout@v6
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - uses: actions/download-artifact@v3
        with:
          name: webpack artifacts
          path: public
      - name: npm install, and test
        run: |
          npm install
          npm test
        env:
          CI: true

# This job publishes the package. `needs: run-npm-test` makes this job dependent on the `run-npm-test` job.
  build-and-push-image:
    runs-on: ubuntu-latest
    needs: run-npm-test 
    # Sets the permissions granted to the `GITHUB_TOKEN` for the actions in this job.
    permissions:
      contents: read
      packages: write 
      #
    steps:
      - name: Checkout
        uses: actions/checkout@v6
      # Uses the `docker/login-action` action to log in to the registry using the account and password that will publish the packages. Once published, the packages are scoped to the account defined here.
      - name: Log in to GitHub Docker Registry
        uses: docker/login-action@65b78e6e13532edd9afa3aa52ac7964289d1a9c1
        with:
          registry: docker.pkg.github.com
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      # This step uses the `docker/build-push-action` action to build the image, based on your repository's `Dockerfile`. If the build succeeds, it pushes the image to GitHub Packages.
      # It uses the `tags` parameter to tag the image with the SHA of the commit that triggered the workflow.
      - name: Build and push Docker image
        uses: docker/build-push-action@f2a1d5e99d037542a71f64918e516c093c6f3fc4
        with:
          push: true
          tags: |
            docker.pkg.github.com/${{ github.repository }}/octo-image:${{ github.sha }}

Этот новый рабочий процесс будет запускаться автоматически при каждой отправке изменения в ветвь с именем release в репозитории. Ход выполнения можно просматривать на вкладке Действия.

Через несколько минут после завершения рабочего процесса новый пакет будет отображаться в репозитории. Чтобы найти доступные пакеты, см. раздел Просмотр пакетов.

Установка пакета с помощью действия

Пакеты можно установить в рамках потока CI с помощью GitHub Actions. Например, можно настроить рабочий процесс так, чтобы в любой момент разработчик отправляет код в запрос на вытягивание, рабочий процесс разрешает зависимости путем скачивания и установки пакетов, размещенных в GitHub Packages. Затем рабочий процесс может выполнять тесты CI, которые требуют зависимости.

При установке пакетов, размещенных с помощью GitHub PackagesGitHub Actions минимальной конфигурации или дополнительной проверки подлинности при использовании GITHUB_TOKEN.

Действия по настройке зависят от клиента пакета. Общие сведения о настройке рабочего процесса для GitHub Actionsсм. в разделе Написание рабочих процессов.

Обновление рабочего процесса, который обращается к реестру с помощью personal access token

GitHub Packages поддерживает простую и безопасную GITHUB_TOKEN проверку подлинности в рабочих процессах. Если вы используете реестр, поддерживающий детализированные разрешения, и рабочий процесс используется personal access token для проверки подлинности в реестре, мы настоятельно рекомендуем обновить рабочий процесс для использования GITHUB_TOKEN.

Дополнительные сведения см. в GITHUB_TOKENразделе Использование GITHUB_TOKEN для проверки подлинности в рабочих процессах.

GITHUB_TOKENС помощью области personal access token (classic)repo вместо области увеличивается безопасность репозитория, так как вам не нужно использовать длительный personal access token доступ к репозиторию, где выполняется рабочий процесс. Дополнительные сведения о рекомендациях по обеспечению безопасности см. в разделе Справочник по безопасному использованию.

1. Перейдите на целевую страницу вашего пакета.

2. В левой боковой панели выберите Доступ к действиям.

3. Чтобы обеспечить доступ пакета к рабочему процессу, необходимо добавить репозиторий, в который хранится рабочий процесс. Click Add репозиторий и поиск репозитория, который требуется добавить.

   Примечание.

   Добавление репозитория в пакет отличается от подключения пакета с **помощью параметра меню "Действия доступа" к репозиторию. Дополнительные сведения см. в разделе [AUTOTITLE и Настройка управления доступом и видимости пакета](/packages/learn-github-packages/connecting-a-repository-to-a-package).

4. При необходимости используйте Раскрывающееся меню роли, чтобы выбрать уровень доступа по умолчанию, который требуется для пакета репозитория.

5. Откройте файл рабочего процесса. В строке, в которой вы входите в реестр, замените егоpersonal access token$.

Например, этот рабочий процесс публикует образ Docker и Container registry использует ${{ secrets.GITHUB_TOKEN }} для проверки подлинности. Дополнительные сведения см. в разделе "Настройка автоматизированных сборок " в документации по Docker.

#
name: Demo Push

# This workflow runs when any of the following occur:
# - A push is made to a branch called `main` or `seed`
# - A tag starting with "v" is created
# - A pull request is created or updated
on:
  push:
    branches:
      - main
      - seed
    tags:
      - v*
  pull_request:
  # This creates an environment variable called `IMAGE_NAME ` with the value `ghtoken_product_demo`.
env:
  IMAGE_NAME: ghtoken_product_demo
#
jobs:
  # This pushes the image to GitHub Packages.
  push:
    runs-on: ubuntu-latest
    permissions:
      packages: write
      contents: read
      #
    steps:
      - uses: actions/checkout@v6

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

      - name: Log in to registry
        run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
        #
      - name: Push image
        run: |
          IMAGE_ID=ghcr.io/${{ github.repository_owner }}/$IMAGE_NAME

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

name: Demo Push

on:
  push:
    branches:
      - main
      - seed
    tags:
      - v*
  pull_request:

env:
  IMAGE_NAME: ghtoken_product_demo

jobs:

  push:
    runs-on: ubuntu-latest
    permissions:
      packages: write
      contents: read

    steps:
      - uses: actions/checkout@v6
      - name: Build image
        run: docker build . --file Dockerfile --tag $IMAGE_NAME --label "runnumber=${GITHUB_RUN_ID}"
      - name: Log in to registry
        run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin

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

          IMAGE_ID=$(echo $IMAGE_ID | tr '[A-Z]' '[a-z]')

          VERSION=$(echo "${{ github.ref }}" | sed -e 's,.*/\(.*\),\1,')

          [[ "${{ github.ref }}" == "refs/tags/"* ]] && VERSION=$(echo $VERSION | sed -e 's/^v//')

          [ "$VERSION" == "main" ] && VERSION=latest
          echo IMAGE_ID=$IMAGE_ID
          echo VERSION=$VERSION
          docker tag $IMAGE_NAME $IMAGE_ID:$VERSION
          docker push $IMAGE_ID:$VERSION

#
name: Demo Push

# This workflow runs when any of the following occur:
# - A push is made to a branch called `main` or `seed`
# - A tag starting with "v" is created
# - A pull request is created or updated
on:
  push:
    branches:
      - main
      - seed
    tags:
      - v*
  pull_request:
  # This creates an environment variable called `IMAGE_NAME ` with the value `ghtoken_product_demo`.
env:
  IMAGE_NAME: ghtoken_product_demo
#
jobs:
  # This pushes the image to GitHub Packages.
  push:
    runs-on: ubuntu-latest
    permissions:
      packages: write
      contents: read
      #
    steps:
      - uses: actions/checkout@v6

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

      - name: Log in to registry
        run: echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin
        #
      - name: Push image
        run: |
          IMAGE_ID=ghcr.io/${{ github.repository_owner }}/$IMAGE_NAME

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