Skip to main content
Мы публикуем частые обновления нашей документации, и перевод этой страницы может все еще выполняться. Актуальные сведения см. в документации на английском языке.

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

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

GitHub Packages доступен в GitHub Free, GitHub Pro, GitHub Free для организаций, GitHub Team, GitHub Enterprise Cloud, GitHub Enterprise Server 3.0 или более поздней версии и GitHub AE.

GitHub Packages недоступен для частных репозиториев, принадлежащих учетным записям, которые используют устаревшие планы для каждого репозитория. Кроме того, учетные записи, использующие устаревшие планы для каждого репозитория, не могут получить доступ к реестрам, поддерживающим детализированные разрешения, так как эти учетные записи оплачиваются репозиторием. Список реестров, поддерживающих детализированные разрешения, см. в разделе Сведения о разрешениях для пакетов GitHub. Дополнительные сведения см. в разделе Продукты GitHub.

Сведения об установке GitHub Packages с помощью GitHub Actions

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

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

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

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

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

Примечание: Возможность для рабочих процессов GitHub Actions удалять и восстанавливать пакеты с помощью REST API в настоящее время находится в общедоступной бета-версии и может быть изменена.

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

Дополнительные сведения о см. в GITHUB_TOKENразделе Автоматическая проверка подлинности токенов. Дополнительные сведения о рекомендациях по использованию реестра в действиях см. в разделе Защита системы безопасности для GitHub Actions.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для автоматической публикации пакетов в рамках потока непрерывной интеграции (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'] ``` Настраивает рабочий процесс Create and publish a Docker image для запуска при каждой отправке изменений в ветвь с именем release.
env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}
Определяет две пользовательские переменные среды для рабочего процесса. Они используются для домена Container registry и имени образа Docker, создаваемого этим рабочим процессом.
jobs:
  build-and-push-image:
    runs-on: ubuntu-latest
Это единственное задание в данном рабочем процессе. Оно настроено для запуска в последней доступной версии 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 в репозитории. Ход выполнения можно просматривать на вкладке Действия.

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

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

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

Установка пакетов, размещенных в GitHub Packages с помощью GitHub Actions, требует минимальной настройки или дополнительной проверки подлинности при использовании GITHUB_TOKEN. Передача данных также является бесплатной при установке пакета действием. Дополнительные сведения см. в разделе Сведения о выставлении счетов за GitHub Packages.

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

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

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

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

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

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

  2. Чтобы пакет получил доступ к рабочему процессу, необходимо добавить в пакет репозиторий, в котором хранится рабочий процесс. В разделе "Управление доступом к действиям" cщелкните Добавить репозиторий и найдите нужный репозиторий. Снимок экрана: раздел "Управление доступом к действиям" на странице параметров пакета. Кнопка "Добавить репозиторий" выделена оранжевым контуром.

    Примечание: Добавление репозитория в пакет с помощью кнопки Добавить репозиторий в разделе "Управление доступом к действиям" в параметрах пакета отличается от подключения пакета к репозиторию. Дополнительные сведения см. в разделах Настройка управления доступом и видимости пакета и Подключение репозитория к пакету.

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

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

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

YAML
name: Demo Push

on:
  push:
    # Publish `main` as Docker `latest` image.
    branches:
      - main
      - 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 personal access token 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" == "main" ] && VERSION=latest
          echo IMAGE_ID=$IMAGE_ID
          echo VERSION=$VERSION
          docker tag $IMAGE_NAME $IMAGE_ID:$VERSION
          docker push $IMAGE_ID:$VERSION