Публикация и установка пакета с помощью 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_TOKENразделе Автоматическая проверка подлинности токенов. Дополнительные сведения о рекомендациях по использованию реестра в действиях см. в разделе Защита системы безопасности для GitHub Actions.

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

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

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

jobs:
  run-npm-build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - 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: [12.x, 14.x]
    steps:
      - uses: actions/checkout@v3
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v3
        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@v3
      - name: Log in to GitHub Docker Registry
        uses: docker/login-action@f054a8b539a109f9f41c372932f1ae047eff08c9
        with:
          registry: docker.pkg.github.com
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - name: Build and push Docker image
        uses: docker/build-push-action@ad44023a93711e3deb337508980b4b5e9bcdc5dc
        with:
          push: true
          tags: |
            docker.pkg.github.com/${{ github.repository }}/octo-image:${{ github.sha }}

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

run-npm-build:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v3
    - 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: [12.x, 14.x]
  steps:
    - uses: actions/checkout@v3
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Откройте файл рабочего процесса. В строке, в которой вы входите в реестр, замените 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