Skip to main content

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например, если рабочий процесс создает контейнер с помощью 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']

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.

```yaml on: push: branches: ['release'] ``` Настраивает рабочий процесс Create and publish a Docker image для запуска при каждой отправке изменений в ветвь с именем release.
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/
Это задание устанавливает NPM и использует его для сборки приложения.
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
Это задание использует npm test для тестирования кода. Команда needs: run-npm-build делает это задание зависимым от задания run-npm-build.
```yaml build-and-push-image: runs-on: ubuntu-latest needs: run-npm-test ``` Это задание публикует пакет. Команда needs: run-npm-test делает это задание зависимым от задания run-npm-test.
```yaml permissions: contents: read packages: write ``` Задает разрешения, предоставляемые GITHUB_TOKEN для действий в этом задании.
```yaml - 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 }} ``` Создает новый шаг с именем Log in to GitHub Docker Registry, выполняющий вход в реестр с помощью учетной записи и пароля, которые будут публиковать пакеты. После публикации пакеты становятся собственностью определенной здесь учетной записи.
```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 push: true ``` Отправляет этот образ в реестр, если он был успешно собран.
```yaml tags: | docker.pkg.github.com/${{ github.repository }}/octo-image:${{ github.sha }} ``` Помечает образ с помощью SHA фиксации, которая активировала рабочий процесс.

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

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

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

  5. Откройте файл рабочего процесса. В строке, в которой вы входите в реестр, замените personal access token ${{ 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 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" == "master" ] && VERSION=latest
          echo IMAGE_ID=$IMAGE_ID
          echo VERSION=$VERSION
          docker tag $IMAGE_NAME $IMAGE_ID:$VERSION
          docker push $IMAGE_ID:$VERSION