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

Сведения об установке 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 можно использовать GITHUB_TOKEN для удаления или восстановления пакета с помощью REST API, если маркер имеет admin разрешение на доступ к пакету. Репозиториям, которые публикуют пакеты с помощью рабочего процесса, и репозиториям, явно подключенным к пакетам, автоматически предоставляется admin разрешение на пакеты в репозитории.

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

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

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

Если вы хотите, чтобы рабочий процесс мог получить доступ к реестру GitHub Packages, который не поддерживает детализированные разрешения, то рекомендуется использовать GITHUB_TOKEN , который GitHub Enterprise Cloud автоматически создает для репозитория при включении 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, по умолчанию:

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

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

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

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

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

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

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

Создайте новый файл рабочего процесса в репозитории (таком как .github/workflows/deploy-image.yml) и добавьте следующий код 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.

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

jobs:
  build-and-push-image:
    runs-on: ubuntu-latest

tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}

Этот новый рабочий процесс будет запускаться автоматически при каждой отправке изменения в ветвь с именем 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 }} для проверки подлинности.

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