GitHub Actions и .NET

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

GitHub Actions

GitHub Actions представляют автономные команды, такие как:

  • действия или проверка out. Это действие проверка в репозитории$GITHUB_WORKSPACE, чтобы рабочий процесс смог получить к нему доступ.
  • actions/setup-dotnet — это действие настраивает среду .NET CLI для использования в действиях.
  • dotnet/versionsweeper . Это действие выполняет очистку репозиториев .NET для устаревших целевых версий .NET.

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

Дополнительные сведения см. в разделе "Общие сведения о действиях GitHub". Думайте о файле рабочего процесса как композиции, представляющей различные шаги для сборки, тестирования и/или публикации приложения. Доступны многие команды ИНТЕРФЕЙСА командной строки .NET, большинство из которых можно использовать в контексте действия GitHub.

Пользовательские действия GitHub

Хотя в Marketplace доступно много действий GitHub, вы можете создать собственный. Вы можете создать GitHub Actions, выполняющие приложения .NET. Дополнительные сведения см. в руководстве по созданию действия GitHub с помощью .NET

Файл рабочего процесса

Действия GitHub используются через файл рабочего процесса. Файл рабочего процесса должен находиться в каталоге github/workflows репозитория и должен быть YAML ( *.yml или *.yaml). Файлы рабочих процессов определяют состав рабочего процесса. Рабочий процесс — это настраиваемый автоматизированный процесс, состоящий из одного или нескольких заданий. Дополнительные сведения см. в статье о синтаксисе рабочего процесса для GitHub Actions.

Примеры файлов рабочего процесса

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

Имя файла рабочего процесса

Description

Компилирует исходный код (или создает). Если исходный код не компилируется, это завершится ошибкой.

Выполняет модульные тесты в репозитории. Чтобы выполнить тесты, исходный код сначала должен быть скомпилирован— это действительно рабочий процесс сборки и тестирования (он заменяет рабочий процесс build-validation.yml ). Сбой модульных тестов приведет к сбою рабочего процесса.

Пакеты и публикует исходный код в месте назначения.

Анализирует код для уязвимостей безопасности и ошибок кодирования. Любые обнаруженные уязвимости могут вызвать сбой.

Зашифрованные секреты

Чтобы использовать зашифрованные секреты в файлах рабочего процесса, ссылайтесь на секреты с помощью синтаксиса выражения рабочего процесса из объекта контекстаsecrets.

${{ secrets.MY_SECRET_VALUE }} # The MY_SECRET_VALUE must exist in the repository as a secret

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

MY_SECRET_VALUE: ***

Внимание

Контекст secrets предоставляет маркер проверки подлинности GitHub, который область в репозиторий, ветвь и действие. Он предоставляется GitHub без вмешательства пользователя:

${{ secrets.GITHUB_TOKEN }}

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

События

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

Пример события веб-перехватчика

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

name: code coverage

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main, staging

jobs:
  coverage:

    runs-on: ubuntu-latest

    # steps omitted for brevity

В предыдущем рабочем процессе pushpull_request и события активируют рабочий процесс для запуска.

Пример запланированного события

В следующем примере показано, как указать триггер события запланированного (cron) для рабочего процесса:

name: scan
on:
  schedule:
  - cron: '0 0 1 * *'
  # additional events omitted for brevity

jobs:
  build:
    runs-on: ubuntu-latest

    # steps omitted for brevity

В предыдущем рабочем процессе событие указывает cron'0 0 1 * *', schedule какой рабочий процесс будет запускаться в первый день каждого месяца. Выполнение рабочих процессов в расписании отлично подходит для рабочих процессов, которые занимают много времени для выполнения или выполнения действий, требующих меньшего внимания.

Пример события вручную

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

name: build
on:
  workflow_dispatch:
    inputs:
      reason:
        description: 'The reason for running the workflow'
        required: true
        default: 'Manual run'
  # additional events omitted for brevity

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: 'Print manual run reason'
        if: ${{ github.event_name == 'workflow_dispatch' }}
        run: |
          echo 'Reason: ${{ github.event.inputs.reason }}'

    # additional steps omitted for brevity

В предыдущем рабочем процессе workflow_dispatch событие требует reason входных данных. GitHub видит это и его пользовательский интерфейс динамически изменяет запрос пользователя на предоставление причины выполнения рабочего процесса вручную. Отпечатывает steps указанную причину от пользователя.

Дополнительные сведения см. в статье События, активирующие рабочие процессы.

Интерфейс командной строки.NET

Интерфейс командной строки (CLI) .NET — это кроссплатформенная цепочка инструментов для разработки, сборки, запуска и публикации приложений .NET. Интерфейс командной строки .NET используется run в рамках отдельного steps файла рабочего процесса. Общая команда:

Дополнительные сведения см. в обзоре .NET CLI

См. также

Дополнительные сведения о GitHub Actions с помощью .NET см. в следующих ресурсах: